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

[Andrei Borzenkov]

В Fri, 24 Apr 2015 20:19:33 +0200
Lennart Poettering <lennart at poettering.net> пишет:

> 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.
> 

I was sure that on reload systemd simply restores previous state of
services. Why it attempts to start anything in the first place?

It makes reload potentially dangerous; what if service was stopped on
purpose and should remain this way?