Bug #1710637 was reported a while back by @Saviq, and I recently started being affected several times a day. Seemingly randomly, pressing Ctrl+C in a gnome-terminal window would log me out of my current session abruptly, returning me to the login screen.
With Laney’s help, I determined that running “snap remove libreoffice” triggered the change to that bad state where the keyboard input would fall through.
Is snapd interacting with setupcon in some way upon removal of a snap?
still use trigger, but use some intelligent filtering so not all devices get reloaded blindly
imagine you plug in a usb key and when removing a snap suddenly your rootfs disk switches from being sda to sdb (there is no guarantee it keeps the name, it can be a matter of order)
well, what for do you do that reload ? it depends … like … do you hae a record of devices that have been touched by the snap ? then you could explicitly only reload these devices for example … just blindly reloading all rules for all devices sounds risky to me.
We reload those rules whenever a snap has interfaces that use the udev backend. If we rewrite the generated udev rules then we reload them. Doing this by subsystem would require us to understand what prior version of the interface did in all cases. We could do that but a) is that a generic solution? b) does it really fix the problem.
well, you are talking about rules your snap has put in place (and removed alongside) so you should know which subsystems, device names or wnatnot have been added/removed from the rule itself … i.e.:
We don’t parse those snippets so we don’t really “know”.
We’d have to adjust the logic to parse the before/after rules and then
see which subsystems are affected. Alternatively we’d have to annotate snippets with side information about subsystems and then store that in a machine-readable way somewhere.
Edit: again, that’s something we can do but we need to understand what is wrong with the current approach exactly.
@zyga-snapd, recently I was playing with udevadm and our cgroups handling and thought I found bugs in our cgroups handling. On reboot I found everything was working fine, so I thought of this thread. I then thought I remembered something about what is safe and not safe and remembered this thread:
This is of course an ancient thread, but this struck me:
"Here’s a quick guide to what is safe to call:
…
I’ve installed udev rules and want udev to do something about it.
udevadm trigger --action=change
...
The action argument is of utmost importance. Without it, the
kernel will tell udev to treat all devices as *NEW*. This will
have lots of side-effects you are probably not expecting.
"change" is completely safe. It tells udev just to refresh
devices, and make sure everything's as it should be.
...
"
I then recalled that udev automatically detects changes to udev rules.
It seems all we need to do is udevadm trigger --action=change and skip everything else. Indeed, looking in /var/lib/dpkg/info/* I see most postinst scripts doing this (some include --subsystem, but thinking that isn’t strictly required).
Looking at this more closely and getting input from others, I don’t think this PR is necessary and is probably unrelated to this issue. I’m closing it now.
I still think the PR makes sense though, forcing a full set of coldplug events for all available devices is pretty wasteful … but yeah, not ugent and not actually related …
I reviewed the bug https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637 and see the underlying cause was an interaction between console-setup udev rules and systemd and it has since been fixed in console-setup, so I will mark this topic as resolved.
I personally think this is a bug in gnome-shell/wayland/gdm since it doesn’t affect gnome-shell/X, only gnome-shell/wayland.
That said, I’d like to take a look to see if we can do something better than our use of udevadm trigger, so I’ve added it to my backlog.
Importantly, need udevadm control --reload-rules which means we don’t need to wait up to 3 seconds for udevd to detect changes and process the new rules. This command is safe as verified by code inspection in src/udev of systemd.
The test is:
add file to /etc/udev/rules.d: sudo sh -c 'echo "KERNEL==\"kmsg\", TAG+=\"snap_hello-world_sh\"" > /etc/udev/rules.d/snap.hello-world.rules'
run udevadm info /dev/kmsg # it should not show a tag
Perhaps other trigger options are possible. Ideally we would trigger on tag match (eg, sudo udevadm trigger --tag-match=snap_hello-world_sh) but this doesn’t work.