Created attachment 86539 [details]
Test case

See README file in tar archive

If a systemctl stop foo command has been given, but the foo service has not yet stopped, and then the systemctl --system daemon-reload is given, then when the foo service eventually stops, systemd will restart it, when clearly it should not.

I speculate that the particular bit of state consisting of the fact that the service is being stopped gets lost in the process of serialization and deserialization.

Since it appears that a reload also occurs for systemctl disable foo, this makes it a particular gotcha for a service that is seeking to stop and disable itself.

Further tests using systemctl is-active before and after the systemctl --system daemon-reload show that the service remains in the state "deactivating" until it stops, so the cause of its being restarted is presumably something rather more subtle than just losing the fact that it's being stopped :(

Then again, I wasn't far off after all.

The Service type's forbid_restart field is not preserved by serialization/deserialization, so the fact that the service should not be restarted after stopping is lost.

I'll submit a proposed patch once I've tested it.

Created attachment 86639 [details] [review]
Patch to correct bug

Patch applied in http://cgit.freedesktop.org/systemd/systemd/commit/?id=6aca9a5.