github-starred/lan-mouse

Fork 0

mirror of https://github.com/feschber/lan-mouse.git synced 2026-05-15 14:15:52 -06:00

[GH-ISSUE #386] Panic in libei.rs:601 "LibeiInputCapture dropped without being terminated" on suspend/resume, causes gnome-shell crash #201

New issue

Open

opened 2026-05-05 22:13:39 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 22:13:39 -06:00

Owner

Originally created by @lleger1 on GitHub (Feb 12, 2026).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/386

Summary

lan-mouse panics at input-capture/src/libei.rs:601 with LibeiInputCapture dropped without being terminated! when the system goes through a suspend/resume cycle. This triggers an assertion failure in gnome-shell's EIS implementation
(eis_seat_destroy: "device list not empty"), causing gnome-shell to crash and dump core.

The issue is reproducible — it happened 3 times in 2 days on the same system.

Environment

lan-mouse: 0.10.0 (Fedora RPM: lan-mouse-0.10.0-1.fc43.x86_64)
OS: Fedora Linux 43 (Workstation Edition)
Kernel: 6.18.8-200.fc43.x86_64
Session: Wayland
GNOME Shell: 49.3-2.fc43
Mutter: 49.3-1.fc43
libei: 1.5.0-1.fc43
xdg-desktop-portal: 1.20.3-2.fc43
xdg-desktop-portal-gnome: 49.0-1.fc43

Steps to Reproduce

Start lan-mouse with a configured client on the local network
Suspend the laptop (close lid or systemctl suspend)
Resume the laptop

What Happens

On resume, the network is not yet available. lan-mouse enters a tight loop (~every 500ms) trying to reach the peer:

WARN lan_mouse::server::ping_task - device not responding, releasing keys!
WARN lan_mouse::server::network_task - udp send failed: network error: `Network is unreachable (os error 101)`

After ~20 seconds of this, the libei input capture session becomes invalid (gnome-shell's EIS backend has restarted), and lan-mouse panics:

thread 'main' panicked at input-capture/src/libei.rs:601:13:
LibeiInputCapture dropped without being terminated!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Crash #1 — Feb 10, 15:35-15:37 (most severe, gnome-shell core dump)

This instance also caused gnome-shell to crash with a core dump:

Feb 10 15:35:33 gnome-shell[2996]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Feb 10 15:35:33 gnome-shell[2996]: EIS: Client error: socket disconnected
Feb 10 15:35:33 xdg-desktop-portal-gnome[3693]: Failed to release captured input: Failed to release: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Capture not active
Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [INFO  lan_mouse::server] deactivated client 0
Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [WARN  lan_mouse::server::emulation_task] ignoring events from client 192.168.0.101:4242
Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [INFO  lan_mouse::server] activated client 0 (right)
Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [WARN  lan_mouse::server::ping_task] client not responding, releasing pointer!
Feb 10 15:37:07 gnome-shell[2996]: EIS: Failed to add device, disconnecting client
Feb 10 15:37:07 gnome-shell[2996]: EIS: Failed to add device, disconnecting client
Feb 10 15:37:07 gnome-shell[2996]: gnome-shell: ../src/libeis-seat.c:40: eis_seat_destroy: Assertion `!"device list not empty"' failed.
Feb 10 15:37:07 gnome-shell[2996]: == Stack trace for context 0x559a0a5f7e90 ==
Feb 10 15:37:07 gnome-shell[2996]: #0   559a0a6c35d8 i   resource:///org/gnome/shell/ui/init.js:21 (209f5df8d8d0 @ 48)
Feb 10 15:37:09 systemd-coredump[22578]: Process 2996 (gnome-shell) of user 1000 dumped core.

Crash #2 — Feb 11, 21:19 (panic + unclean exit)

Feb 11 21:19:04 de.feschber.LanMouse.desktop[25888]: [WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
Feb 11 21:19:04 de.feschber.LanMouse.desktop[25888]: [WARN  lan_mouse::server::network_task] udp send failed: network error: `Network is unreachable (os error 101)`
Feb 11 21:19:05 gnome-shell[24298]: g_settings_get_value: assertion 'G_IS_SETTINGS (settings)' failed
Feb 11 21:19:05 gnome-shell[24298]: g_variant_get_type: assertion 'value != NULL' failed
Feb 11 21:19:05 gnome-shell[24298]: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed
Feb 11 21:19:05 gnome-shell[24298]: g_variant_get_boolean: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_BOOLEAN)' failed
[... ~20 seconds of "device not responding, releasing keys!" every 500ms ...]
Feb 11 21:19:24 de.feschber.LanMouse.desktop[25888]: thread 'main' panicked at input-capture/src/libei.rs:601:13:
Feb 11 21:19:24 de.feschber.LanMouse.desktop[25888]: LibeiInputCapture dropped without being terminated!
Feb 11 21:19:24 /usr/libexec/xdg-desktop-portal[24784]: Failed to close session implementation: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path
"/org/freedesktop/portal/desktop/session/1_93/ashpd_kK49xM3IBa"

Expected Behavior

lan-mouse should gracefully handle suspend/resume by:

Detecting that the network is down and backing off (exponential backoff instead of 500ms tight loop)
Properly terminating the LibeiInputCapture session before dropping it
Reconnecting to the EIS/libei backend after gnome-shell restarts, rather than panicking

Impact

The gnome-shell crash caused by the eis_seat_destroy assertion failure can lead to a full system freeze, requiring a hard reset. On Btrfs filesystems, a hard reset can cause the filesystem to remount as read-only on the next boot.

Current Workaround

I created a systemd service to kill lan-mouse before suspend:

# /etc/systemd/system/stop-lanmouse-before-sleep.service
[Unit]
Description=Stop lan-mouse before sleep to prevent gnome-shell crash
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/usr/bin/pkill -x lan-mouse

[Install]
WantedBy=sleep.target

Suggested Fix

The panic at libei.rs:601 should be replaced with graceful error handling — either properly calling terminate() on the LibeiInputCapture before drop, or converting the panic to an error log and attempting to recreate the session.

Originally created by @lleger1 on GitHub (Feb 12, 2026). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/386 ## Summary lan-mouse panics at `input-capture/src/libei.rs:601` with `LibeiInputCapture dropped without being terminated!` when the system goes through a suspend/resume cycle. This triggers an assertion failure in gnome-shell's EIS implementation (`eis_seat_destroy: "device list not empty"`), causing gnome-shell to crash and dump core. The issue is reproducible — it happened 3 times in 2 days on the same system. ## Environment - **lan-mouse**: 0.10.0 (Fedora RPM: lan-mouse-0.10.0-1.fc43.x86_64) - **OS**: Fedora Linux 43 (Workstation Edition) - **Kernel**: 6.18.8-200.fc43.x86_64 - **Session**: Wayland - **GNOME Shell**: 49.3-2.fc43 - **Mutter**: 49.3-1.fc43 - **libei**: 1.5.0-1.fc43 - **xdg-desktop-portal**: 1.20.3-2.fc43 - **xdg-desktop-portal-gnome**: 49.0-1.fc43 ## Steps to Reproduce 1. Start lan-mouse with a configured client on the local network 2. Suspend the laptop (close lid or systemctl suspend) 3. Resume the laptop ## What Happens On resume, the network is not yet available. lan-mouse enters a tight loop (~every 500ms) trying to reach the peer: ``` WARN lan_mouse::server::ping_task - device not responding, releasing keys! WARN lan_mouse::server::network_task - udp send failed: network error: `Network is unreachable (os error 101)` ``` After ~20 seconds of this, the libei input capture session becomes invalid (gnome-shell's EIS backend has restarted), and lan-mouse panics: ``` thread 'main' panicked at input-capture/src/libei.rs:601:13: LibeiInputCapture dropped without being terminated! note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` ## Crash #1 — Feb 10, 15:35-15:37 (most severe, gnome-shell core dump) This instance also caused gnome-shell to crash with a core dump: ``` Feb 10 15:35:33 gnome-shell[2996]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed Feb 10 15:35:33 gnome-shell[2996]: EIS: Client error: socket disconnected Feb 10 15:35:33 xdg-desktop-portal-gnome[3693]: Failed to release captured input: Failed to release: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Capture not active Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [INFO lan_mouse::server] deactivated client 0 Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [WARN lan_mouse::server::emulation_task] ignoring events from client 192.168.0.101:4242 Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [INFO lan_mouse::server] activated client 0 (right) Feb 10 15:36:17 de.feschber.LanMouse.desktop[15530]: [WARN lan_mouse::server::ping_task] client not responding, releasing pointer! Feb 10 15:37:07 gnome-shell[2996]: EIS: Failed to add device, disconnecting client Feb 10 15:37:07 gnome-shell[2996]: EIS: Failed to add device, disconnecting client Feb 10 15:37:07 gnome-shell[2996]: gnome-shell: ../src/libeis-seat.c:40: eis_seat_destroy: Assertion `!"device list not empty"' failed. Feb 10 15:37:07 gnome-shell[2996]: == Stack trace for context 0x559a0a5f7e90 == Feb 10 15:37:07 gnome-shell[2996]: #0 559a0a6c35d8 i resource:///org/gnome/shell/ui/init.js:21 (209f5df8d8d0 @ 48) Feb 10 15:37:09 systemd-coredump[22578]: Process 2996 (gnome-shell) of user 1000 dumped core. ``` ## Crash #2 — Feb 11, 21:19 (panic + unclean exit) ``` Feb 11 21:19:04 de.feschber.LanMouse.desktop[25888]: [WARN lan_mouse::server::ping_task] device not responding, releasing keys! Feb 11 21:19:04 de.feschber.LanMouse.desktop[25888]: [WARN lan_mouse::server::network_task] udp send failed: network error: `Network is unreachable (os error 101)` Feb 11 21:19:05 gnome-shell[24298]: g_settings_get_value: assertion 'G_IS_SETTINGS (settings)' failed Feb 11 21:19:05 gnome-shell[24298]: g_variant_get_type: assertion 'value != NULL' failed Feb 11 21:19:05 gnome-shell[24298]: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed Feb 11 21:19:05 gnome-shell[24298]: g_variant_get_boolean: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_BOOLEAN)' failed [... ~20 seconds of "device not responding, releasing keys!" every 500ms ...] Feb 11 21:19:24 de.feschber.LanMouse.desktop[25888]: thread 'main' panicked at input-capture/src/libei.rs:601:13: Feb 11 21:19:24 de.feschber.LanMouse.desktop[25888]: LibeiInputCapture dropped without being terminated! Feb 11 21:19:24 /usr/libexec/xdg-desktop-portal[24784]: Failed to close session implementation: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path "/org/freedesktop/portal/desktop/session/1_93/ashpd_kK49xM3IBa" ``` ## Expected Behavior lan-mouse should gracefully handle suspend/resume by: 1. Detecting that the network is down and backing off (exponential backoff instead of 500ms tight loop) 2. Properly terminating the `LibeiInputCapture` session before dropping it 3. Reconnecting to the EIS/libei backend after gnome-shell restarts, rather than panicking ## Impact The gnome-shell crash caused by the `eis_seat_destroy` assertion failure can lead to a full system freeze, requiring a hard reset. On Btrfs filesystems, a hard reset can cause the filesystem to remount as read-only on the next boot. ## Current Workaround I created a systemd service to kill lan-mouse before suspend: ```ini # /etc/systemd/system/stop-lanmouse-before-sleep.service [Unit] Description=Stop lan-mouse before sleep to prevent gnome-shell crash Before=sleep.target [Service] Type=oneshot ExecStart=/usr/bin/pkill -x lan-mouse [Install] WantedBy=sleep.target ``` ## Suggested Fix The panic at `libei.rs:601` should be replaced with graceful error handling — either properly calling `terminate()` on the `LibeiInputCapture` before drop, or converting the panic to an error log and attempting to recreate the session.

gitea-mirror commented

2026-05-05 22:13:42 -06:00

Author

Owner

@nbolton commented on GitHub (Feb 12, 2026):

@whot ^

@nbolton commented on GitHub (Feb 12, 2026): @whot ^

gitea-mirror commented

2026-05-05 22:13:42 -06:00

Author

Owner

@feschber commented on GitHub (Feb 12, 2026):

The "dropped without being terminated" panic should be fixed in the development version (0.10.0 is quite old at this point, there is going to be a new release, soon).

I'm not sure if this is actually the root cause.
I tried to reproduce this on my system (GNOME 49.2) and couldn't reproduce a crash...

It may have something to do with lan-mouse trying to disable and close a session that no longer exists but I really cant tell:

[2026-02-12T16:07:02Z WARN  input_capture::libei] input_capture.disable(&session) Portal request failed: org.freedesktop.zbus.Error: Invalid session
[2026-02-12T16:07:02Z WARN  input_capture::libei] session.close(): Portal request failed: org.freedesktop.zbus.Error: Object does not exist at path “/org/freedesktop/portal/desktop/session/1_1472/ashpd_jxffAgNJ4L”

I will try this out on Fedora, when I have the time.

@feschber commented on GitHub (Feb 12, 2026): The "dropped without being terminated" panic should be fixed in the development version (0.10.0 is quite old at this point, there is going to be a new release, soon). I'm not sure if this is actually the root cause. I tried to reproduce this on my system (GNOME 49.2) and couldn't reproduce a crash... It may have something to do with lan-mouse trying to disable and close a session that no longer exists but I really cant tell: ``` [2026-02-12T16:07:02Z WARN input_capture::libei] input_capture.disable(&session) Portal request failed: org.freedesktop.zbus.Error: Invalid session [2026-02-12T16:07:02Z WARN input_capture::libei] session.close(): Portal request failed: org.freedesktop.zbus.Error: Object does not exist at path “/org/freedesktop/portal/desktop/session/1_1472/ashpd_jxffAgNJ4L” ``` I will try this out on Fedora, when I have the time.

gitea-mirror commented

2026-05-05 22:13:43 -06:00

Author

Owner

@whot commented on GitHub (Feb 12, 2026):

A crash in gnome-shell cannot be a bug in lan-mouse (though we're grateful for lan-mouse triggering it so we can fix it ;). Crash 1 particular one looks like a bug in libeis, hitting an assertion means something internal has gone wrong. Can you file this issue with libei please (and also make sure that you're using the latest libei, 1.5.0 is the latest so you're good there).

Crash 2 looks like a gnome-shell issue too

Feb 11 21:19:05 gnome-shell[24298]: g_settings_get_value: assertion 'G_IS_SETTINGS (settings)' failed

This shouldn't really ever happen - gnome-shell (possibly via mutter) tries to read a gsettings but the value is not available. Usually this doesn't happen unless you run a combo of different git versions and not all have been updated - it certainly shouldn't happen in a released version. The resulting 20s of timeout could well be the DBus timeout.

So if all you're using are the rpms, then yes, this is a bug in libeis and gnome-shell, by the looks of it. And maybe one in lan-mouse, I leave that one up to @feschber :)

@whot commented on GitHub (Feb 12, 2026): A crash in gnome-shell cannot be a bug in lan-mouse (though we're grateful for lan-mouse triggering it so we can fix it ;). Crash 1 particular one looks like a bug in libeis, hitting an assertion means something internal has gone wrong. Can you file this issue with [libei](https://gitlab.freedesktop.org/libinput/libei/) please (and also make sure that you're using the latest libei, 1.5.0 is the latest so you're good there). Crash 2 looks like a gnome-shell issue too ``` Feb 11 21:19:05 gnome-shell[24298]: g_settings_get_value: assertion 'G_IS_SETTINGS (settings)' failed ``` This shouldn't really ever happen - gnome-shell (possibly via mutter) tries to read a gsettings but the value is not available. Usually this doesn't happen unless you run a combo of different git versions and not all have been updated - it certainly shouldn't happen in a released version. The resulting 20s of timeout could well be the DBus timeout. So if all you're using are the rpms, then yes, this is a bug in libeis and gnome-shell, by the looks of it. And maybe one in lan-mouse, I leave that one up to @feschber :)