[systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

Ivan Shapovalov intelfx100 at gmail.com
Sat Jan 17 17:21:02 PST 2015

Hi folks,

I'm trying to fix this bug:

The initial problem (as reported) looks following: performing a reload
(maybe implicitly) re-starts alsa-restore.service if it is enabled.

With a bit of debugging I've apparently found a root cause. Explanation

Suppose we have CUPS installed and org.cups.cupsd.{path,service} are

We enter manager_reload(), units are serialized, reset, re-read,
deserialized and then cold-plugged. (Note that e. g. unit_notify() has
special "protection" to avoid spawning jobs when a reload is in

So, if org.cups.cupsd.path is started, *it is almost first to be
cold-plugged*. The call chain is:

path_enter_waiting() // recheck == true
path_check_good() // returns true
manager_add_job() // at this point we're fucked up

So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
because a reload should never enqueue any jobs (IIUC). So, the job is
enqueued... remember that almost all units are inactive by now. Thus we
end up re-starting half a system (the whole basic.target) as

- is my analysis correct?
- if yes, then how to fix this? Maybe add a similar
  "if (UNIT(p)->manager->n_reloading <= 0)" check to
  path_enter_running() to avoid calling manager_add_job() during

Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150118/8f67a50f/attachment.sig>

More information about the systemd-devel mailing list