Re: [systemd-devel] Having my script blocking all other scripts until it ends
On 2015-09-24 10:39:33, EXT Luca Bertoncello wrote: > > > Could you rephrase this question? > > Well, my script does something that require time and all other processes > on the server MUST run during this operation. > > But right now, after systemd execute my "stop script", it prosecute and > stop all other processes at the same time (or almost). > > > Then my question: how can I block the "shutdown process" until my script > is done? Is your service that shall block the subsequent ones in shutdown of Type "oneshot". I'd expect that the same that is valid for startup is also valid for shutdown. Quoting systemd.service(5) manpage: Type= [...] Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units. This implies "blocking behaviour", AFAIU. -Vivenzio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Modifying systemd dependency tree during boot
Hi, we face a problem with systemd when we attempt to dynamically add dependencies to units during bootup. In other words, we want to add services during boot (by means of some service that is run during boot) and via "systemctl daemon-reload" we want to notify systemd about this new units and start them (due to WantedBy dependencies of that newly created units to a later to be reached target). In principle, what we have is a system where part of the SW is not (yet) available at the beginning of boot, when systemd builds up its dependency tree. During boot, a unit will eventually mount a filesystem where additional SW is located that shall be started on bootup. It would be desirable to boot them each as separate systemd units (so we could use e.g. process supervision etc.). We tried to have a "scanner service" that comes up after the filesystem is available. This service will scan a well-known directory in that filesystem for SW to be started. The scanning procedure would result in the creation of new service files executing that SW. These services should "hook in" via [Install] section. When finished with service creation, this "scanner service" would issue a "systemctl daemon-reload" to make the new dependencies to the newly created units effective to systemd. Here an (hopefully not too abstract) example: 1. The target used to "pull in" the dynamically created service units. I would use multi-user.target here. 2. The "scanner service", let's call it scanner.service that searches programs on the newly available filesystem. 3. The "scanned services"; in my test I made a template and the scanner.service will enable instantiations of that, depending on which SW is found on the filesystem. scanner.service: = [Unit] WantedBy = multi-user.target Before = multi-user.target RequiresMountsFor = /path/to/fs [Service] Type = oneshot ExecStart = /usr/bin/scan-for-programs /path/to/fs scanned@.service: == [Unit] Description = Program %i from (late) filesystem WantedBy = multi-user.target Before= multi-user.target [Service] ExecStart = /path/to/fs/%i * The scan-for-programs utility would: a. for all found programs in /path/to/fs: enable scanned@program.service b. call systemctl daemon-reload to make the changes of step a. effective. [Note: Actually, part a. can also be implemented as a generator which would be called implicitly by the subsequent daemon-reload, but the end result remains the same.] However, these additionally added services are not started, when trying to reach multi-user.target. After boot, I can see that the dependencies where added correctly (e.g. doing "systemctl list-dependencies multi-user.target" lists the newly created services as dependencies, but they remain inactive). I suspect that something is wrong with this approach, but I do not understand, what. My assumption is that during boot it is not supported to fiddle with the "dependency graph" dynamically (i.e. before the boot reaches its final unit). Is this correct? If so, is there a rationale for that? If this approach is wrong, what would be a better systemd-based approach of solving such a problem of "starting SW that is available only later during bootup"? -Vivenzio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Instantiated services in presets
Hi, currently I work on a system that boots with systemd and is well-described by what is termed stateless system in http://0pointer.net/blog/projects/stateless.html. In that system unit enabling is not stored persistently, so I introduced to usage of presets to define a policy what needs to be enabled on bootup. Doing so I realized that this works nice for ordinary units, however instantiated units will not get enabled via presets. So there seems to be an asymmetry in handling of instantiated services between preset-enabled and manually-enabled (i.e. by means of systemctl enable ... command) units. I try to give a tabular summary of what is the current behaviour: This table assumes a unit template X@.service that has an [Install] section telling how to enable that service (e.g. WantedBy=multi-user.target). Additionally, it defines a DefaultInstance there as well. The unit Y.service is a plain service, not a template. enable action presetmanual comment - enable Yworks works non-template case enable X@ works works enables DefaultInstance* enable X@x works not works differing behaviour Footnotes: * DefaultIntance is defined in X@.service, there can be only one such instance I tested this with v222. The question is now if this is intended behaviour or a bug? Personally, I find this confusing, since presets are there to define a (default) policy, whereas unit templates are there for unit reuse. Two different goals that should not interfere. Hence my expectation would be that instatiated services should work well with presets as well. Can someone give me some enlighenment here, maybe I did not get the ideas well? Cheers, Vivenzio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Instantiated services in presets
On 2015-08-06 12:21:33, ext Lennart Poettering wrote: On Thu, 06.08.15 12:10, Vivenzio Pagliari (vivenzio.pagli...@nokia.com) wrote: [... presets] works nice for ordinary units, however instantiated units will not get enabled via presets. So there seems to be an asymmetry in handling of instantiated services between preset-enabled and manually-enabled (i.e. by means of systemctl enable ... command) units. [...] enable action presetmanual comment - enable Yworks works non-template case enable X@ works works enables DefaultInstance* enable X@x works not works differing behaviour Footnotes: * DefaultIntance is defined in X@.service, there can be only one such instance I tested this with v222. The question is now if this is intended behaviour or a bug? Personally, I find this confusing, since presets are there to define a (default) policy, whereas unit templates are there for unit reuse. Two different goals that should not interfere. Hence my expectation would be that instatiated services should work well with presets as well. Yes, the preset logic does not cover what you are trying to do. It works by iterating through the available unit files, and then matching them against the preset file, not the other way round, how it would be necessary for what you are trying to do. What you can do is use the Alias= setting in the [Install] section to create multiple symlinks: for example, if you write a unit file my-little-getty@.service you could add this to it: [Install] Alias=multi-user.target.wants/my-little-getty@foo.service multi-user.target.wants/my-little-getty@bar.service And so on... THat said, I think we really should change DEfaultInstance= to take a list of instances, not just one... Aliases (or a list of instances accepted as DefaultInstance(s)) may solve the problem. However, I still have a conceptual problem: If I want to enable cetain instances by policy, I would like to do so in the preset, but not in the unit file itself. The [Install] section of a unit file describes the enable-behaviour, but not the enable-policy, AFAIU. So from my perspective there would still be a desire to use preset as if I would do systemctl enable ... by hand. Your argument above describes that preset logic seems to be different from manual enable logic. Is this an implemenation detail or is this deliberately designed so? If it is just impemenation detail, does it make sense to adjust it to work like manual systemctl enable? cheers, Vivenzio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Typo fix in systemd.preset manpage
According to SYNOPSIS (and implementation) the preset files shall be named *.preset. However, the 'PRESET FILE FORMAT' section of the manpage tells something different, which is incorrect. Vivenzio Pagliari (1): Typo fix in systemd.preset manpage man/systemd.preset.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.4.6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Typo fix in systemd.preset manpage
--- man/systemd.preset.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml index 2f9add8..b716401 100644 --- a/man/systemd.preset.xml +++ b/man/systemd.preset.xml @@ -106,7 +106,7 @@ one takes precedence over all others./para paraEach preset file shall be named in the style of -filenamelt;prioritygt;-lt;programgt;.conf/filename. Files +filenamelt;prioritygt;-lt;policy-namegt;.preset/filename. Files in filename/etc//filename override files with the same name in filename/usr/lib//filename and filename/run//filename. Files in filename/run//filename override files with the same -- 2.4.6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
