Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

Lorenz lorenzo.ru.g at gmail.com
Sun Jan 27 02:20:46 GMT 2019


I manage to reproduce this with systemd, in a Virtualbox VM.
here are the steps, after booting with systemd as init
* stop udev
   # systemctl stop systemd-udevd
   make sure there is no 'systemd-udevd' process list in pstree
* start udev in background like this
   # setsid --fork /lib/systemd/systemd-udevd
   OR like this
   # start-stop-daemon --start --name systemd-udevd --exec
/lib/systemd/systemd-udevd --background
   in any case make sure udedv is running
* try one of the following (wait few seconds after prompt)
   # udevadm trigger --type=subsystems action=add
   # udevadm trigger --type=devices action=add
   # udevadm settle

As a result all process belonging to you session are crashed and restarted;
if you are doing this in a VT you get kicked out and the screen is cleared;
if you are doing this in a graphical session you get the login screen of
display manager (I use slim + lxqt ).
This is a bit different from what happens when init is not systemd, in that
i belive systemd-logind is constraining the killing within the session ( or
the slice),
but ... Final Bonus Weirdness:
if you start udevd in background in the VT session, then go to the graphic
session and prompt a udevadm command from there, it's the VT session that
get crashed.

This was introduced in commit e803efca

when udevd is run in background and it's not detached  with it's own
'--daemonize' option,
then a udevadm command is enough to kill everything.
The commits uses 'start-stop-daemon' with '--background' option, so it
triggered a bug that
was already in the code since who-knows-when.. i can reproduce this also
with another VM
(stretch) that has systemd 232-25.

Non-Systemd users can workaround this by using the init script from systemd


or by editing the current init script replacing the --background option
with ' -- --daemonize".
(some other adjustments are nedded to the script)
Be aware that in both case this will reintroduce bug #791944

Dear Systemd Maintainers,
still you can't reproduce this? Can you please say something?


Il giorno gio 24 gen 2019 alle ore 08:36 Gedalya <gedalya at gedalya.net> ha

> Hi,
> With the help of snapshot.d.o, I've found that the problem first appeared
> in 239-8.
> I've also been able to trigger it by restarting udev and running 'udevadm
> control --log-priority=debug'.
> Still no insight on what is the factor causing this to happen on some
> machines and not on others.
> Regards,
> Gedalya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20190127/0fddb021/attachment.html>

More information about the Debian-init-diversity mailing list