Desktop/apps don't receive uevents (hardware changes)

[martinpitt]

A running sway desktop does not recognize new input devices (such as plugging in a Yubikey), changed monitors (docking/undocking), or USB drives. This is most probably because it does not receive any uevents: udevadm monitor -e --udev does not do anything in swaypod. The kernel's netlink socket is an abstract Unix socket, so it can't simply be bind-mounted.

This does not work in a standard Fedora toolbox either. I am not sure if this can be made to work at all with current Linux/podman -- if not, then that is a dealbreaker, and the "run desktop in container" concept is fundamentally broken.

[martinpitt]

This is not a new topic, see e.g.

• https://dummdida.tumblr.com/post/118770655240/udev-events-in-containers and https://dummdida.tumblr.com/post/121087781445/re-udev-events-in-a-container
• https://stackoverflow.com/questions/49687378/how-to-get-hosts-udev-events-from-a-docker-container
• https://github.com/containers/toolbox/issues/468

But the container already uses --network=host and bind-mounting /dev.

[martinpitt]

I filed a toolbox issue and also asked on Mastodon, perhaps some great mind has an idea?

[martinpitt]

@brauner implemented uevent forwarding in the kernel a few years ago, and pointed me to https://github.com/lxc/lxd/pull/5099 which implements an uevent forwarder in lxd. Curiously the actually interesting piece of code is commented out. In principle this isn't difficult, though: "You can receive the uevent in the host netns, then you cut off it's seqnum field, write it into a uevent socket of the target netns (of the container) and the kernel will append a new seqnum and send it to the target netns.". This is a great thing to try on my next long train ride or so :grin: Thanks Christian!

@89luca89 created https://github.com/89luca89/distrobox/. This is very similar to toolbox (especially while it was still in shell). I quickly tested that (thanks for making it trivial to run straight out of git!), and unsurprisingly it suffers from the same problem, there is no mechanics for forwarding uevents. So once we have some solution, that may be interesting for you as well?

[brauner]

@brauner implemented uevent forwarding in the kernel a few years ago, and pointed me to lxc/lxd#5099 which implements an uevent forwarder in lxd. Curiously the actually interesting piece of code is commented out. In principle this isn't difficult, though: "You can receive the uevent in the host netns, then you cut off it's seqnum field, write it into a uevent socket of the target netns (of the container) and the kernel will append a new seqnum and send it to the target netns.". This is a great thing to try on my next long train ride or so 😁 Thanks Christian!

@89luca89 created https://github.com/89luca89/distrobox/. This is very similar to toolbox (especially while it was still in shell). I quickly tested that (thanks for making it trivial to run straight out of git!), and unsurprisingly it suffers from the same problem, there is no mechanics for forwarding uevents. So once we have some solution, that may be interesting for you as well?

@martinpitt the code isn't commented out. It's cgo ad it's called from a constructor in another file. :)