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
Hi,
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
your
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
https://salsa.debian.org/systemd-team/systemd/commit/e803efca59978aa5bb1d8806247f986d0c0f7e67
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
239-7
https://salsa.debian.org/systemd-team/systemd/blob/debian/239-7/debian/udev.init
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?
Lorenz
Il giorno gio 24 gen 2019 alle ore 08:36 Gedalya <gedalya at gedalya.net> ha
scritto:
> 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://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190127/0fddb021/attachment.html>
More information about the Pkg-systemd-maintainers
mailing list