Bug Description
The process crashes after ~5-6 minutes with EMFILE (too many open files) when running under GNOME Wayland. The crash repeats with consistent timing until the parent process gives up.
Environment
- OS: Linux (Manjaro)
- Compositor: GNOME Wayland
- Clipboards: WlrClipboard (wayland-1) + X11Clipboard (:1)
- ulimit -n: 1024
Error
thread 'main' panicked at wayland-client-0.29.4/src/rust_imp/proxy.rs:211:39:
Sending a message failed.: EMFILE
Root Cause
WlrClipboard::get() and WlrClipboard::set() (src/clipboard.rs) call wl_clipboard_rs::paste::get_contents() and wl_clipboard_rs::copy::Options::copy() respectively. Each call opens a new Wayland connection (socket fd + shm fds), and these connections/fds are not properly cleaned up before the next call.
The polling loop in keep_synced() / await_change() (src/sync.rs) calls get() every 200ms per clipboard, and every clipboard change triggers set() on all clipboards. With 2 clipboards this creates ~10+ Wayland connections per second, leaking fds each time, exhausting the fd limit within ~5-6 minutes.
Relevant Code
src/clipboard.rs:60-81 — WlrClipboard::get() creates a new Wayland connection per call
src/clipboard.rs:83-98 — WlrClipboard::set() creates a new Wayland connection per call
src/sync.rs:246-261 — await_change() polls via get() every 200ms
src/sync.rs:61-72 — keep_synced() calls set() on all clipboards on every change
Proposed Fix
Use WlCommandClipboard (already implemented in src/clipboard.rs:102-134 as a fallback) as the primary Wayland clipboard backend instead of WlrClipboard. It uses wl-paste/wl-copy subprocesses which clean up after themselves, avoiding the fd leak entirely. This requires:
- Changing
WlCommandClipboard::should_poll() to return true
- Switching
get_wayland() to prefer WlCommandClipboard
Crash Timeline
Each restart survives consistently ~5-6 minutes before hitting EMFILE:
| Start |
Crash |
Uptime |
| 14:50:44 |
14:56:17 |
~5.5 min |
| 14:56:18 |
15:01:39 |
~5.3 min |
| 15:01:40 |
15:07:14 |
~5.5 min |
| 15:07:15 |
15:12:42 |
~5.5 min |
Full Logs
Details
2026-07-06 14:50:44 - INFO - started clipboard sync manager
2026-07-06 14:50:44 - INFO - starting clipboard sync
Invalid MIT-MAGIC-COOKIE-1 key
2026-07-06 14:50:44 - WARN - Issue connecting to some x11 clipboards. This is expected when hooking up to gnome wayland, and not a problem in that context. Details: 'clipboard error: X11 clipboard error : XCB connection error: Connection' for x11 displays: [0, 2..254]
2026-07-06 14:50:44 - INFO - Using clipboards: [WlrClipboard { display: "wayland-1" }, X11Clipboard { display: ":1" }]
2026-07-06 14:50:51 - INFO - clipboard updated from display :1
2026-07-06 14:51:33 - INFO - clipboard updated from display wayland-1
2026-07-06 14:51:36 - INFO - clipboard updated from display wayland-1
2026-07-06 14:52:26 - INFO - clipboard updated from display wayland-1
2026-07-06 14:52:32 - INFO - clipboard updated from display wayland-1
2026-07-06 14:55:47 - INFO - clipboard updated from display :1
2026-07-06 14:55:55 - INFO - clipboard updated from display wayland-1
2026-07-06 14:56:12 - INFO - clipboard updated from display :1
2026-07-06 14:56:15 - INFO - clipboard updated from display :1
thread 'main' (31697) panicked at /build/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wayland-client-0.29.4/src/rust_imp/proxy.rs:211:39:
Sending a message failed.: EMFILE
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2026-07-06 14:56:17 - FATAL - child process 31697 panicked. giving it another try
2026-07-06 14:56:18 - INFO - starting clipboard sync
Invalid MIT-MAGIC-COOKIE-1 key
2026-07-06 14:56:18 - WARN - Issue connecting to some x11 clipboards. This is expected when hooking up to gnome wayland, and not a problem in that context. Details: 'clipboard error: X11 clipboard error : XCB connection error: Connection' for x11 displays: [0, 2..254]
2026-07-06 14:56:18 - INFO - Using clipboards: [WlrClipboard { display: "wayland-1" }, X11Clipboard { display: ":1" }]
2026-07-06 14:56:23 - INFO - clipboard updated from display :1
2026-07-06 14:57:44 - INFO - clipboard updated from display :1
2026-07-06 14:59:58 - INFO - clipboard updated from display wayland-1
2026-07-06 15:00:23 - INFO - clipboard updated from display wayland-1
2026-07-06 15:00:30 - INFO - clipboard updated from display wayland-1
2026-07-06 15:00:44 - ERROR - error getting status of child process 31697: ECHILD: No child processes
2026-07-06 15:00:44 - ERROR - error killing child process 31697: ESRCH: No such process
thread 'main' (32766) panicked at /build/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wayland-client-0.29.4/src/rust_imp/proxy.rs:211:39:
Sending a message failed.: EMFILE
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2026-07-06 15:01:39 - FATAL - child process 32766 panicked. giving it another try
(repeats 4 times total)
thread 'main' (31696) panicked at src/main.rs:81:25:
child process 34966 panicked too many times.
Bug Description
The process crashes after ~5-6 minutes with
EMFILE(too many open files) when running under GNOME Wayland. The crash repeats with consistent timing until the parent process gives up.Environment
Error
Root Cause
WlrClipboard::get()andWlrClipboard::set()(src/clipboard.rs) callwl_clipboard_rs::paste::get_contents()andwl_clipboard_rs::copy::Options::copy()respectively. Each call opens a new Wayland connection (socket fd + shm fds), and these connections/fds are not properly cleaned up before the next call.The polling loop in
keep_synced()/await_change()(src/sync.rs) callsget()every 200ms per clipboard, and every clipboard change triggersset()on all clipboards. With 2 clipboards this creates ~10+ Wayland connections per second, leaking fds each time, exhausting the fd limit within ~5-6 minutes.Relevant Code
src/clipboard.rs:60-81—WlrClipboard::get()creates a new Wayland connection per callsrc/clipboard.rs:83-98—WlrClipboard::set()creates a new Wayland connection per callsrc/sync.rs:246-261—await_change()polls viaget()every 200mssrc/sync.rs:61-72—keep_synced()callsset()on all clipboards on every changeProposed Fix
Use
WlCommandClipboard(already implemented insrc/clipboard.rs:102-134as a fallback) as the primary Wayland clipboard backend instead ofWlrClipboard. It useswl-paste/wl-copysubprocesses which clean up after themselves, avoiding the fd leak entirely. This requires:WlCommandClipboard::should_poll()to returntrueget_wayland()to preferWlCommandClipboardCrash Timeline
Each restart survives consistently ~5-6 minutes before hitting EMFILE:
Full Logs
Details