В Fri, 24 Apr 2015 20:19:33 +0200 Lennart Poettering <lenn...@poettering.net> пишет:
> 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. > 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? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
