Bug 85156

Summary: Reloading systemd config causes ExecStartPre in unchanged units to run more than once
Product: systemd Reporter: Jonathan Short <jonathan.short>
Component: generalAssignee: systemd-bugs
Status: RESOLVED FIXED QA Contact: systemd-bugs
Severity: normal    
Priority: medium CC: jonathanboulle
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Jonathan Short 2014-10-17 19:29:50 UTC
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.
Comment 1 Lennart Poettering 2014-10-20 17:11:45 UTC
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?)?
Comment 2 Kane Kim 2014-10-20 18:16:10 UTC
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?
Comment 3 Lennart Poettering 2014-10-20 18:18:38 UTC
(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.
Comment 4 Lennart Poettering 2017-10-27 18:17:31 UTC
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.