[systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

Ivan Shapovalov intelfx100 at gmail.com
Fri Apr 24 14:16:09 PDT 2015


On 2015-04-24 at 20:19 +0200, Lennart Poettering wrote:
> On Fri, 24.04.15 20:46, Ivan Shapovalov (intelfx100 at gmail.com) wrote:
> 
> > On 2015-04-24 at 19:13 +0200, Lennart Poettering wrote:
> > > On Fri, 24.04.15 20:06, Ivan Shapovalov (intelfx100 at 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 /
-------------- 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/20150425/e051e7c2/attachment.sig>


More information about the systemd-devel mailing list