Random niri crash

[TheAngusMcFire]

I got a random niri crash with this error message: I did nothing special, it just crashed.

Jun 14 19:57:20 arch-tower-pc niri[10379]: libinput error: event3  - Logitech G Pro Gaming Mouse: client bug: event processing lagging behind by 50ms, your system is too slow
Jun 14 19:58:24 arch-tower-pc niri[10379]: error marshalling arguments for send: dup failed: Too many open files
Jun 14 19:58:24 arch-tower-pc niri[10379]: 2024-06-14T17:58:24.650624Z  WARN niri::niri: error inserting client: Too many open files (os error 24)
Jun 14 19:58:24 arch-tower-pc niri[10379]: thread 'main' panicked at src/main.rs:260:10:
Jun 14 19:58:24 arch-tower-pc niri[10379]: called `Result::unwrap()` on an `Err` value: OtherError(Os { code: 24, kind: Uncategorized, message: "Too many open files" })
Jun 14 19:58:24 arch-tower-pc niri[10379]: stack backtrace:
Jun 14 19:58:24 arch-tower-pc niri[10379]: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Jun 14 19:58:25 arch-tower-pc niri[10379]: 2024-06-14T17:58:25.009808Z DEBUG niri::utils::watcher: exiting watcher thread for /home/user/.config/niri/config.kdl
Jun 14 19:58:25 arch-tower-pc systemd[10235]: niri.service: Main process exited, code=exited, status=101/n/a
Jun 14 19:58:25 arch-tower-pc systemd[10235]: niri.service: Failed with result 'exit-code'.
Jun 14 19:58:25 arch-tower-pc systemd[10235]: niri.service: Consumed 26min 8.423s CPU time, 89.9M memory peak, 0B memory swap peak.

System Information

• niri version: 0.1.6

• Distro: arch linux

• GPU: amd rx 6600 xt

• CPU: ryzen2700

[TheAngusMcFire]

another thing I noticed: I think it has something todo with the clipboard-sync (https://github.com/dnut/clipboard-sync) application, It was the only thing I changed about my setup...

[YaLTeR]

Huh, that's a weird crash.

another thing I noticed: I think it has something todo with the clipboard-sync (https://github.com/dnut/clipboard-sync) application, It was the only thing I changed about my setup...

Maybe there's a fd leak going on? Hard to tell without debugging.

[YaLTeR]

ls -al /proc/$(pgrep niri)/fd/ around the time when you suspect a crash is about to happen could shed some light on the issue.

Otherwise, try niri-git since bcca03cce7da9dc4125aa34943041cb65e0fd4bb might work around the problem.

[YaLTeR]

Oops, accidentally clicked the wrong button.

[TheAngusMcFire]

Hi, sorry for the late response. It really seems that the clipboard-sync util creates an obscene amount of fds lik this:

lrwx------ angus angus 64 B Wed Jun 19 23:08:25 2024  254 ⇒ socket:[82167] lrwx------ angus angus 64 B Wed Jun 19 23:08:25 2024  255 ⇒ socket:[82167] lrwx------ angus angus 64 B Wed Jun 19 23:08:25 2024  256 ⇒ socket:[82169] lrwx------ angus angus 64 B Wed Jun 19 23:08:25 2024  257 ⇒ socket:[82169]

I guess it crashes at about 1000 or something, it happens quite fast. I will try niri-git now.

[TheAngusMcFire]

Yes, it is not crashing with niri-git Thanks a lot for the help and the awesome Wayland compositor. I love niri.

[YaLTeR]

Do these fds get cleaned up at some point? For example if you kill clipboard-sync? If there's a fd leak in niri we still want to fix it

[TheAngusMcFire]

I think the problem is clipboard-sync, I do not really know how it works but it seems after some time something internally crashes within clipboard-sync, after that all the FDs get cleaned up. I did not check but I think clipboard-check is not reusing/closing the connections correctly.