/lib/systemd/system/systemd-udev-trigger.service contains multiple ExecStart ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger --type=devices --action=add If, after the first ExecStart, systemd is interrupted with a daemon-reload, the other ExecStart parts are never executed. [ 4.474521] cnyk systemd[1]: About to execute: /usr/bin/udevadm trigger --type=subsystems --action=add [ 4.474615] cnyk systemd[1]: Forked /usr/bin/udevadm as 231 [ 4.474695] cnyk systemd[1]: systemd-udev-trigger.service changed dead -> start [ 4.474712] cnyk systemd[1]: Expecting device dev-disk-by\x2duuid-400cb83b\x2d3fad\x2d46bc\x2da71b\x2d0e34a4cfa373.device... [ 4.474984] cnyk systemd[231]: Executing: /usr/bin/udevadm trigger --type=subsystems --action=add [ 4.475882] cnyk systemd[1]: Expecting device dev-disk-by\x2duuid-5f5e62a5\x2d3143\x2d4bcf\x2d9d38\x2d968791cd4e16.device... [ 4.477043] cnyk systemd[1]: Expecting device dev-disk-by\x2duuid-67040d2c\x2d2f85\x2d42f8\x2dafb8\x2de667d90f09da.device... [ 4.478198] cnyk systemd[1]: Set up jobs progress timerfd. [ 4.478202] cnyk systemd[1]: Set up idle_pipe watch. [ 4.479278] cnyk systemd[1]: Received SIGHUP from PID 1 (systemd). [ 4.479287] cnyk systemd[1]: Received SIGCHLD from PID 215 (n/a). [ 4.479293] cnyk systemd[1]: Reloading. ... [ 5.694420] cnyk systemd[1]: Received SIGCHLD from PID 231 (udevadm). [ 5.694449] cnyk systemd[1]: Got SIGCHLD for process 231 (udevadm) [ 5.694485] cnyk systemd[1]: Child 231 died (code=exited, status=0/SUCCESS) [ 5.694488] cnyk systemd[1]: Child 231 belongs to systemd-udev-trigger.service [ 5.694499] cnyk systemd[1]: systemd-udev-trigger.service: main process exited, code=exited, status=0/SUCCESS [ 5.694579] cnyk systemd[1]: systemd-udev-trigger.service changed start -> exited [ 5.694584] cnyk systemd[1]: Job systemd-udev-trigger.service/start finished, result=done [ 5.694616] cnyk systemd[1]: Started udev Coldplug all Devices.
The problem here is that we have trouble recognizing the same ExecStart= lines before and after we did the reload, hence we currently don't try at all. i.e. let's say you have three ExecStart= lines: ExecStart=/bin/foo ExecStart=/bin/bar ExecStart=/bin/waldo Let's say you are now executing /bin/bar. And now you reload the daemon, but the /bin/bar one was removed, what do you do now, at which point do you continue? And what happens if it's /bin/foo you remove too? And what happens when you delete all three and replace them with ExecStart=/bin/huhu? We should probably do something about this and try to come up with a scheme that at least most of the time manages to continue at some sane point. But I am not sure what the best scheme here would be? Ideas?
(In reply to comment #1) > The problem here is that we have trouble recognizing the same ExecStart= > lines before and after we did the reload, hence we currently don't try at > all. > > i.e. let's say you have three ExecStart= lines: > > ExecStart=/bin/foo > ExecStart=/bin/bar > ExecStart=/bin/waldo > > Let's say you are now executing /bin/bar. And now you reload the daemon, but > the /bin/bar one was removed, what do you do now, at which point do you > continue? And what happens if it's /bin/foo you remove too? And what happens > when you delete all three and replace them with ExecStart=/bin/huhu? > > We should probably do something about this and try to come up with a scheme > that at least most of the time manages to continue at some sane point. But I > am not sure what the best scheme here would be? Ideas? Well, maybe delay the daemon-reload until a point of time, where we can safely do that.
But that could be indefinitely long... It's not really an option I fear...
If a unit file has been modified after a unit is started, and before it stops, then it's probably fair to say that the behaviour is undefined. But a unit whose file is unmodified shouldn't have a behaviour that depends on the timing of entirely unrelated reload events, otherwise multiple ExecStart commands are rather useless, unless one doesn't care that much about whether they get executed.
Should be fixed by github #5354 these days. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.