Originally filed against fleet project: https://github.com/coreos/fleet/issues/973. This is systemd version 215 running on CoreOS. -- Description -- Unit files and script demonstrating issue: http://filebin.ca/1dxpnTpXmJ4z/repro_final.tar.gz. Running 410.2.0. Run the run.sh script to reproduce the issue, then check fleetctl journal unit1.service. The example files are a simplified example of our original code. This seems timing related so most of the original contents of the unit file have been replaced with sleeps. Output of fleetctl journal unit1.service (note unit1_starting appears twice - should be once): Oct 15 11:22:56 core-02 systemd[1]: Starting Unit1... Oct 15 11:22:57 core-02 bash[4878]: unit1_starting Oct 15 11:23:03 core-02 bash[4917]: unit1_starting Oct 15 11:23:10 core-02 sudo[4928]: core : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/systemctl set-environment UNIT1=xxx Oct 15 11:23:13 core-02 systemd[1]: Started Unit1. Output of journalctl: http://filebin.ca/1dxv3kRBcU3X/journalctl.txt -- Comment 1 -- Hmm, I haven't dived into this too deeply but I am fairly sure it's a result of daemon-reload getting called while the ExecStartPre of unit1 is still occurring. Not sure whether that's expected behaviour or not. For example, I seem to be able to simulate the same behaviour by running systemctl start unit1.service and then systemctl daemon-reload in another terminal (while the start is blocking). Would be interesting to know whether that causes the same issues you're experiencing too. --- I asked in IRC #systemd whether this was a bug, the answer came back yes: 10:35 <jonathan_> I filed an issue with fleet (https://github.com/coreos/fleet/issues/973) that appears to be a systemd issue (coreos is running version 215). The issue is that systemctl daemon-reload is run while a unit is starting and in an ExecStartPre=. The unit gets started again (runs same ExecStartPre=) without going through any stop state first. Just wondering if that is a known issue, expected behavior, or a bug. 10:41 <michich> jonathan_, a bug. 10:44 <michich> on the other hand, if the unit file changed, then it's not easy to tell what the correct behavior should be 11:31 <jonathan_> @michich thanks. that makes sense. the unit file didn't change in this case so sounds straightforward.
Yeah, this is a known issue, but I am not sure what the correct behaviour is if the unit files are modified: try to rememebr the number of the ExecStartPre= line we were last processing? Try to find it again by comparing the whole command line (but what would we do if we don#t find it?)?
I think it's fine (and better) to rerun if unit file has changed. Shouldn't it call stop on previous unit, before running the updated one?
(In reply to Kane Kim from comment #2) > I think it's fine (and better) to rerun if unit file has changed. Shouldn't > it call stop on previous unit, before running the updated one? Well, I am pretty sure we shouldn't trigger per-daemon restarts if the user just wants to reload systemd's own configuration.
This has been fixed in v234. 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.