Error report appeared in the egui tool

[vi]

Error: an I/O error occurred
Details: Core(
    Io {
        error: Os {
            code: 1,
            kind: PermissionDenied,
            message: "Operation not permitted",
        },
        context: "Failed to kill other egui instance: Pid(19580).",
    },
)

The banner persists (with the same pid) across ringboard-egui restarts.

[SUPERCILEX]

If this happens again or is still happening, can you run ps -p $PID where $PID is whatever the number is? Also do you use multiple user accounts? And are you on Wayland?

My theory is that the PID is left over from an old egui instance but got reused by another application. I think I'll either need to check the binary name (dunno how to make this resilient to file renames) or delete the file before quitting egui (which will be a PitA with the current architecture).

[vi]

Currently not happening. Xorg. Multiple accounts are used, but ringboard-egui is supposed to be launched only from one account. 19580 is gone.

delete the file before quitting egui

I expect it to be a typical behavior of pidfiles. Stale pidfile is a sign of a crash or improper reboot.

Maybe ringboard-egui should use other, gentle mechanism to close unneeded instance? For example, a real-time or other mild signal that won't cause unrelated app to close. Or just make it listen to a UNIX socket and exit based on notification on that socket.

Trying to terminate a process using stale pid is like trying to close filesystem descriptor that was already closed - it may invite a sudden problem elsewhere.

[SUPERCILEX]

I think I'll have to rework how the reopen trigger works. Right now you delete a file to reopen egui, but that's not great. I think it should work like this: egui creates a PID file while running and deletes it when quitting, then it registers an open listener (or maybe a file attribute listener) so that you can touch the file to reopen.

[vi]

What do you mean by "reopen"? ringboard-egui is not resident - the process exits when I choose an item from history or close the window.

What is difference between "reopening" and just starting ringboard-egui again?

[SUPERCILEX]

Check the process list with ps: it'll still be there unless you manually installed without specifying --no-default-features --features x11. Makes launch times feel significantly faster.

[vi]

I don't remember what commit ringboard-egui is from (maybe even different from ringboard-server). ringboard-server is compiled with default features off, but I don't remember what feature set was chosen for ringboard-egui.

The process (as seen by e.g. ps aux | rg egui) gets started (by i3) when I press the hotkey, gets replaced by a new process when I press the hotkey again (without closing old window) and disappears when I close the window normally.

Launch time is already almost imperceptible (maybe around 200-300 milliseconds).

---

inotify+pidfile scheme may be OK, though it adds another dependency on a kernel feature that may be absent in the installation.

Why not just use a UNIX socket like the server? Connect to it and sent a signal to re-show the window. If fails, remove the socket and bind it again and show the window.

[SUPERCILEX]

The old window should get closed if the PID file wasn't broken for you. But anyway, see these docs for the running process reopen: https://github.com/SUPERCILEX/clipboard-history/tree/master/egui#suggested-workflow

[vi]

/tmp/.ringboard/$USER.egui-sleep typically points to a stale pidfile and removing it does not produce anything visible.

It does not respond to RUST_LOG=debug.

This is a list of syscalls when I start ringboard-egui, then close the window:

`strace -cf /opt/ringboard/ringboard-egui`

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- -------------------
 88.96    0.972910        8609       113         3 futex
  8.05    0.088033          50      1730           poll
  0.70    0.007648           7       960        12 ioctl
  0.49    0.005308           3      1462       590 recvmsg
  0.40    0.004407           5       862           writev
  0.33    0.003610          11       322           mmap
  0.18    0.001951          39        50           munmap
  0.11    0.001249         104        12           madvise
  0.10    0.001095           1      1044           getpid
  0.09    0.000959           1       481        78 read
  0.07    0.000744           9        77           rt_sigprocmask
  0.07    0.000738           4       179        29 openat
  0.05    0.000586           5       101           mprotect
  0.04    0.000478           2       164           epoll_ctl
  0.04    0.000458           3       120           write
  0.04    0.000408           5        78           epoll_wait
  0.04    0.000408          29        14           clone3
  0.04    0.000397           2       162           close
  0.04    0.000395           5        77         1 recvfrom
  0.02    0.000265           1       167        15 newfstatat
  0.02    0.000235           3        78           timerfd_settime
  0.02    0.000222           2       111        86 readlink
  0.01    0.000146           1        83           brk
  0.01    0.000109           7        15           set_robust_list
  0.01    0.000100           6        15           rseq
  0.01    0.000097           9        10           sched_setaffinity
  0.01    0.000091           8        11           prctl
  0.01    0.000080           6        13           statx
  0.01    0.000075           7        10           sigaltstack
  0.00    0.000051           4        12           getdents64
  0.00    0.000036           9         4         2 connect
  0.00    0.000036           4         8           sendmsg
  0.00    0.000036           2        16           getrandom
  0.00    0.000033           5         6           sched_getaffinity
  0.00    0.000031           6         5         1 access
  0.00    0.000030           7         4           socket
  0.00    0.000026           2        11           fcntl
  0.00    0.000019           6         3           memfd_create
  0.00    0.000018           2         9           sched_yield
  0.00    0.000011           2         4           uname
  0.00    0.000011           3         3           ftruncate
  0.00    0.000011           1         7           geteuid
  0.00    0.000007           7         1           getpeername
  0.00    0.000007           3         2         1 linkat
  0.00    0.000006           6         1           getsockname
  0.00    0.000006           0         8           getuid
  0.00    0.000006           6         1           setpriority
  0.00    0.000005           2         2           getegid
  0.00    0.000003           3         1           sched_setscheduler
  0.00    0.000003           3         1           unlinkat
  0.00    0.000003           3         1           inotify_init1
  0.00    0.000002           2         1           lseek
  0.00    0.000002           0         6           rt_sigaction
  0.00    0.000002           1         2           gettid
  0.00    0.000001           1         1           inotify_add_watch
  0.00    0.000000           0         2           pread64
  0.00    0.000000           0         4           mremap
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1         1 kill
  0.00    0.000000           0         3           getgid
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         1           timerfd_create
  0.00    0.000000           0         2           eventfd2
  0.00    0.000000           0         1           epoll_create1
  0.00    0.000000           0         2           prlimit64
------ ----------- ----------- --------- --------- -------------------
100.00    1.093604         126      8660       819 total

Though I don't remember commit or feature set, the executable has debuginfo, if something is needed.

[SUPERCILEX]

It should definitely be listening because there's the inotify_add_watch syscall. If an egui instance is running but the window is closed, then removing the sleep file should reopen the window of the existing instance (the PID file needs to be up to date).

[vi]

If I remove /tmp/.ringboard/$USER.egui-sleep without closing the window, it gets re-created. The window does not pop to front or something like that, it stays minimized.

If the window is open and focused and I switch away to another i3 workspace, then deleting /tmp/.ringboard/$USER.egui-sleep causes the window to signal for attention (but it does not get visible) - I see workspace with the window getting indication. If I hide the window with Ctrl+N, it stays hidden when the file is removed.

Look like resident mode it not the best for my setup and simple (unoptimised) mode just works well enough. So after series of fixes, the oneshot mode should be supported one way or another.

---

inotify_add_watch syscall

I have noted it, but I also noted the exit_group(0) at the end, suggesting that it just exists willingly (not crashes or something).

[SUPERCILEX]

I guess it just doesn't play well with i3. If you want to disable the feature completely, compile with default features and the reopen stuff will be disabled.

Anyway, I don't have access to a computer for the next month, but I'll fix the PID issues once I get back.

[SUPERCILEX]

Why not just use a UNIX socket like the server? Connect to it and sent a signal to re-show the window. If fails, remove the socket and bind it again and show the window.

Forgot to address this. Very reasonable solution, but then you still need a PID file to avoid having multiple instances of egui running (which is a property I'd like to vaguely uphold). Also I'm not sure if everybody would have the right version of netcat.

---

So I looked at options for stuff to listen to for inotify and remembered why I went with delete: any kind of open style listener will trigger if the user is just trying to cat the file so that's a no go. And I discovered I'm dumb lol! @vi the reason the listener doesn't work for you is because I had remapped rm on my old machine to actually move files to trash, so my listener was for move events. I've now made the listener work on both delete and move events which definitely feels hacky but oh well.