<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>I manage to reproduce this with systemd, in a Virtualbox VM.</div><div>here are the steps, after booting with systemd as init</div><div>* stop udev</div><div>   # systemctl stop systemd-udevd</div><div>   make sure there is no 'systemd-udevd' process list in pstree</div><div>* start udev in background like this</div><div>   # setsid --fork /lib/systemd/systemd-udevd</div><div>   OR like this</div><div>   # start-stop-daemon --start --name systemd-udevd --exec /lib/systemd/systemd-udevd --background</div><div>   in any case make sure udedv is running</div><div>* try one of the following (wait few seconds after prompt)</div><div>   # udevadm trigger --type=subsystems action=add</div><div>   # udevadm trigger --type=devices action=add</div><div>   # udevadm settle</div><div><br></div><div>As a result all process belonging to you session are crashed and restarted;</div><div>if you are doing this in a VT you get kicked out and the screen is cleared;</div><div>if you are doing this in a graphical session you get the login screen of your</div><div>display manager (I use slim + lxqt ).</div><div>This is a bit different from what happens when init is not systemd, in that</div><div>i belive systemd-logind is constraining the killing within the session ( or the slice), </div><div>but ... Final Bonus Weirdness: </div><div>if you start udevd in background in the VT session, then go to the graphic </div><div>session and prompt a udevadm command from there, it's the VT session that get crashed.</div><div><br></div><div>This was introduced in commit e803efca</div><div><a href="https://salsa.debian.org/systemd-team/systemd/commit/e803efca59978aa5bb1d8806247f986d0c0f7e67">https://salsa.debian.org/systemd-team/systemd/commit/e803efca59978aa5bb1d8806247f986d0c0f7e67</a><br></div><div><br></div><div>when udevd is run in background and it's not detached  with it's own '--daemonize' option,</div><div>then a udevadm command is enough to kill everything.</div><div>The commits uses 'start-stop-daemon' with '--background' option, so it triggered a bug that</div><div>was already in the code since who-knows-when.. i can reproduce this also with another VM</div><div>(stretch) that has systemd 232-25.</div><div><br></div><div>Non-Systemd users can workaround this by using the init script from systemd 239-7</div><div><br></div><div><a href="https://salsa.debian.org/systemd-team/systemd/blob/debian/239-7/debian/udev.init">https://salsa.debian.org/systemd-team/systemd/blob/debian/239-7/debian/udev.init</a><br></div><div><br></div><div>or by editing the current init script replacing the --background option with ' -- --daemonize".</div><div>(some other adjustments are nedded to the script)</div><div>Be aware that in both case this will reintroduce bug #791944</div><div><br></div><div>Dear Systemd Maintainers,</div><div>still you can't reproduce this? Can you please say something?</div><div><br></div><div>Lorenz</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 24 gen 2019 alle ore 08:36 Gedalya <<a href="mailto:gedalya@gedalya.net">gedalya@gedalya.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
With the help of snapshot.d.o, I've found that the problem first appeared in 239-8.<br>
<br>
I've also been able to trigger it by restarting udev and running 'udevadm control --log-priority=debug'.<br>
<br>
Still no insight on what is the factor causing this to happen on some machines and not on others.<br>
<br>
Regards,<br>
<br>
Gedalya<br>
<br>
<br>
</blockquote></div>