Re: [systemd-devel] clarification on daemon-reload
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 >> network, generate unit files and place them under /run and then call >> systemctl daemon-reload, then it would work. But if daemon-reload does >> not affect what was already scheduled, then I need a better plan. > > One option is to add a target you enqueue after installing the new > configuration and reloading. Then, add all units that shall start to > it as dependencies. Thanks, that is a nice solution that does not sounds like a workaround! And if a custom-network-loaded config wants to disable a services that would be otherwise started by default, it could just mask it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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 implement initialization when the > configuration comes from a drive that is not available during early > boot like virtio mount or uploaded from a network connection? Clearly > I can write a new persistent config and reboot the system for the new > changes to take an affect, but I would prefer to keep all the config > changes under /run so reboot always brings the system into a clean > state. I.e. how one should implement a staged boot when the system > performs a minimal initialization like mounting some paths or > initializing a minimal networking, gets the rest of the config via > that and then run the rest of initialization? One option is to do this from the initrd: mount your alternative config source from there, and then when doing the full root transition already have all the data you need around. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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 not available during early boot like virtio mount or uploaded from a network connection? Clearly I can write a new persistent config and reboot the system for the new changes to take an affect, but I would prefer to keep all the config changes under /run so reboot always brings the system into a clean state. I.e. how one should implement a staged boot when the system performs a minimal initialization like mounting some paths or initializing a minimal networking, gets the rest of the config via that and then run the rest of initialization? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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 to run and then B alters or > even disables A and calls systemctl daemon-reload. > > > I'm not entirely sure what systemd can sensibly do in this case though. > > 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 cannot use a systemd.generator as the > service depends on a mounted directory. Well, my recommendation is to avoid daemon-reloads during the normal boot process if possible, since there are some unresolved issues: If you run a service with multiple ExecStart= lines, we currently do not remember at which one we are while doing a daemon reload (simply because it's not clear how to solve this comprehensively: should we go by line number or should we search for the same command line? -- after all the precise set of ExecStart= lines might have changed due to the reload). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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 systemd > uses the new definition for A, right? > > In particular, if according to the new configuration A should not run at > all because B changed the systemd configuration so A is no longer required > by any units, then systemd does not run A, right? No, what is queued is queued. A daemon-reload should leave the execution queue unmodified, neither remove nor add new entries. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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 then B alters or > even disables A and calls systemctl daemon-reload. > In this case stopping B would be a bug. "Requires" dependency is only ever considered when you start unit. But B could have been started manually, so stopping it would be wrong. >> I'm not entirely sure what systemd can sensibly do in this case though. > > 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 cannot use a systemd.generator as the > service depends on a mounted directory. As I already said, daemon-reload should not trigger any unit state change itself. But I do not think it is set as documented API anywhere. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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 cannot use a systemd.generator as the > service depends on a mounted directory. You could have a generator that first create a one-shot .service if it's directory is not mounted at boot. This one-shot .service looks like that: | [Unit] | RequiresMountsFor=/directory | After= | | [Service] | Type=oneshot | ExecStart=/bin/sh -c "/usr/bin/systemctl daemon-reload ; /usr/bin/systemctl try-restart your-service" At it's second run (when called by daemon-reload), the generator does the right thing. The /bin-sh -c "..." is needed to encapsulate the try-restart; if it's not there, as this .service file doesn't exist anymore; the try-restart is never run. It's ugly, but it works reliably. Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
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-reload. > I'm not entirely sure what systemd can sensibly do in this case though. 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 cannot use a systemd.generator as the service depends on a mounted directory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
В 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 and then B calls systemctl daemon-reload. Then the systemd > uses the new definition for A, right? > > In particular, if according to the new configuration A should not run at > all because B changed the systemd configuration so A is no longer required > by any units, then systemd does not run A, right? I do not think so. AFAIU, daemon-reload should not cause any unit state change. Which can be quite confusing if you modify e.g. ExecStart line to do something entirely different - it will show unit as started with new definition while it actually runs with old one. I'm not entirely sure what systemd can sensibly do in this case though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
