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 <[email protected]> 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 > > >
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
