On 2015-04-24 at 20:19 +0200, Lennart Poettering wrote: > On Fri, 24.04.15 20:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: > > > On 2015-04-24 at 19:13 +0200, Lennart Poettering wrote: > > > On Fri, 24.04.15 20:06, Ivan Shapovalov (intelfx...@gmail.com) > > > wrote: > > > > > > > With this patch applied, on `systemctl daemon-reload` I get the > > > > following: > > > > > > Any chance you can do the same with debugging on? "systemd > > > -analyze > > > set-log-level debug" right before the daemon-reload? > > > > > > That should show the transaction being queued in. > > > > Sure, I've ran it (log attached), but well... it did not show > > any new jobs being enqueued. But alsa-restore.service _did_ run and > > did reset my ALSA volume to the bootup value. > > > > Pretty confused, > > Note that starting services is recursive: if a service is enqueued, > then we add all its dependencies to the transaction, verify that the > transaction is without cycles and can be applied, and then actually > apply it. > > This means, that starting a service foo.service, that requires > bar.target, that requires waldo.service, will mean that waldo.service > is also started, even if bar.target is already started anyway.
Judging by current master, this is not the case. I've created a pair of throw-away services and a target in the described configuration, and dependencies of an already started target are not started again. I think the status quo is correct because activating an already activated target is a no-op. Anyway, this is orthogonal. The issue at hand is that the core looks at the state of not-yet-coldplugged units... -- Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
