Re: [systemd-devel] clarification on daemon-reload

2015-05-19 Thread Igor Bukanov
On 19 May 2015 at 12:08, Lennart Poettering wrote: > On Tue, 19.05.15 08:22, Igor Bukanov (i...@mir2.org) wrote: >> In any case, I thought that if I add >> a dependency like After=my-config-is-ready.target for most default >> services that can be configured, load a config from a mount or >> networ

Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 17:53, Igor Bukanov (i...@mir2.org) wrote: > On 18 May 2015 at 17:18, Lennart Poettering wrote: > > Well, my recommendation is to avoid daemon-reloads during the normal > > boot process if possible, since there are some unresolved issues: > > What is then a canonical way to impl

Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Igor Bukanov
On 18 May 2015 at 17:18, Lennart Poettering wrote: > Well, my recommendation is to avoid daemon-reloads during the normal > boot process if possible, since there are some unresolved issues: What is then a canonical way to implement initialization when the configuration comes from a drive that is

Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Lennart Poettering
On Mon, 18.05.15 07:51, Igor Bukanov (i...@mir2.org) wrote: > On 18 May 2015 at 05:35, Andrei Borzenkov wrote: > > > > > > What exactly do you mean? It has RefuseManualStart set? > > I meant that, for example, A is enabled and contains Requires=B and > this is the only dependency that causes B t

Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Lennart Poettering
On Sun, 17.05.15 10:06, Igor Bukanov (i...@mir2.org) wrote: > Hello, > > suppose a unit B runs just because another unit A contains Requires=B and > After=B. When B runs, it changes A like adding new dependencies, altering > Exec command etc and then B calls systemctl daemon-reload. Then the syst

Re: [systemd-devel] clarification on daemon-reload

2015-05-18 Thread Andrei Borzenkov
On Mon, May 18, 2015 at 8:51 AM, Igor Bukanov wrote: > On 18 May 2015 at 05:35, Andrei Borzenkov wrote: >> >> >> What exactly do you mean? It has RefuseManualStart set? > > I meant that, for example, A is enabled and contains Requires=B and > this is the only dependency that causes B to run and t

Re: [systemd-devel] clarification on daemon-reload

2015-05-17 Thread Alexandre Detiste
Le lundi 18 mai 2015, 07:51:18 Igor Bukanov a écrit : > What I would like to know is what is the exact behavior of systemctl > daemon-reload. I am writing a service that creates/modifies other > units by placing files under /run and I would like to know what are > the limitations. In my case I cann

Re: [systemd-devel] clarification on daemon-reload

2015-05-17 Thread Igor Bukanov
On 18 May 2015 at 05:35, Andrei Borzenkov wrote: > > > What exactly do you mean? It has RefuseManualStart set? I meant that, for example, A is enabled and contains Requires=B and this is the only dependency that causes B to run and then B alters or even disables A and calls systemctl daemon-reloa

Re: [systemd-devel] clarification on daemon-reload

2015-05-17 Thread Andrei Borzenkov
В Sun, 17 May 2015 10:06:28 +0200 Igor Bukanov пишет: > Hello, > > suppose a unit B runs just because another unit A contains Requires=B and What exactly do you mean? It has RefuseManualStart set? > After=B. When B runs, it changes A like adding new dependencies, altering > Exec command etc an

[systemd-devel] clarification on daemon-reload

2015-05-17 Thread Igor Bukanov
Hello, suppose a unit B runs just because another unit A contains Requires=B and After=B. When B runs, it changes A like adding new dependencies, altering Exec command etc and then B calls systemctl daemon-reload. Then the systemd uses the new definition for A, right? In particular, if according