Re: [systemd-devel] Support for staged startup
On Thu, 29.01.15 17:20, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: > Hi all, > > I'd like to realize a staged startup with systemd which is mainly about: > - starting up a static tree up to a final service > - the only job of the final service is to kick off the start of an additional > sub tree of units > > This kind of startup could be realized simply by adding an additional one > shot service which executes: systemctl start xxx.target > > My question now is: Is this the appropriate way for realizing this > or is there any other more elegant way. My problem with this > approach is that systemd executes a binary (systemctl), which > communicates with systemd just to queue a new job in systemd. Sounds > as if there should be a way which is a bit more direct ... This has come up before, for example here: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019187.html I think generally it is a better idea to push as many IO and CPU workloads into the kernel as possible, plus appropriate scheduling settings and let it figure out the rest, than trying to work around it by pushing things into the kernel only bit-by-bit, like you would do with such a "staged" startup. We already added support for applying different scheduling settings during startup then during normal operating to help with this. What I'd still like to see changed in systemd proper is permitting the user to control which job to execute first if multiple jobs are runnable at the same time. Currently the order is undefined (though not random). If you really want to do a "staged" boot-up then invoking "systemctl start --no-block" from a service is the option of choice I figure... 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] Support for staged startup
Hello, thx for the answer. > Why not start the final sub-tree units the conventional way, but make > them all wait, listening on sockets?A final service need not > contain a 'systemctl start xxx.target' command, as instead it could > simply write a message to those sockets. Some services could receive a > signal telling them to terminate, and others telling them to continue. > Ok good idea. But finally this is (effort wise) the same like calling systemctl (kick off one process, which communicates via IPC with another one). If it is now my own socket or the systemd control socket does not really matter. > Given that it's possible to specify the startup service in the kernel > command line with "system.unit=", the engineer configuring the startup > sequence could specify a variety of alternate dependency > trees.Each tree would have a different unit at its head.The > units in one tree need not appear in another at all, or they could > appear in the second tree in a different order. > That's possible as well but might get a bit too complex for a bit more dynamics. This finally depends probably on the actual use case. Ok I guess what I learned from your answers now is that the systemctl approach is probably the best one for my concrete use case. Thx all for sharing your thoughts. Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Hello, thx for the answer. > If you do not use "--no-block" to start your second target, first > target will never finish. That's something I cannot confirm. If you define the service, which is calling "systemctl start xxx", as oneshot the service will be in state activating for exactly the time needed to bring up the target. > Other caveat of your way is that systemd doesn't know about your final > target until it receives "systemctl start destination.target". Since it > doesn't know about the target, units that are requested by > destination.target will not have the default dependencies applied. That's true but wanted in my case ;) Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Marko Hoyer writes:
> > - starting up a static tree up to a final service
> > - the only job of the final service is to kick off the start of an
> > additional sub tree of units This kind of startup could be realized
> > simply by adding an additional one shot service which executes:
> > systemctl start xxx.target
Why not start the final sub-tree units the conventional way, but make
them all wait, listening on sockets?A final service need not
contain a 'systemctl start xxx.target' command, as instead it could
simply write a message to those sockets. Some services could receive
a signal telling them to terminate, and others telling them to
continue.
> 2.) If you wanna create some dynamics between target A and target B so that
> depending on the startup situation services
> are already started before A or in another round they are delayed until A is
> done, you probably need to disconnect them
> from the static startup tree and pull them in dynamically at the desired time.
Given that it's possible to specify the startup service in the kernel
command line with "system.unit=", the engineer configuring the
startup sequence could specify a variety of alternate dependency
trees.Each tree would have a different unit at its head.The
units in one tree need not appear in another at all, or they could
appear in the second tree in a different order.
-- Alison
--
Alison Chaiken ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals. -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
I asked:
>> I don't know of any use case for one unit to start another directly.
>> Is there one?
Marko responds:
> 1.) Coming up with a small tree first reduces the loading time of the unit
> set (not so much important in my case)
>
> 2.) If you wanna create some dynamics between target A and target B so that
> depending on the startup situation services are already started before A or
> in another round they are delayed until A is done, you probably need to
> disconnect them from the static startup tree and pull them in dynamically at
> the desired time.
systemd includes 19 conditionals (see './systemd
--dump-configuration-items | grep Cond').The first, static set of
services can therefore use a variety of signals like symlinks or file
modification times to signal the second wave of services.You
could, for example, write a script to dynamically change where
default.target points depending on whether ConditionKernelCommandLine
contains certain bootargs or ConditionFirstBoot is TRUE. These
signals are in addition to the more usual ones implemented by
sd_notify().
If there's a real need to check a different type of Condition, it
would be more in keeping with the spirit of systemd to add the new
Condition functionality than to have one unit specifically invoke
another.
-- Alison
--
Alison Chaiken ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals. -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Hi,
What you have figured out is so far the only way if you want to have
dynamic targets.
If you do not use "--no-block" to start your second target, first
target will never finish.
Other caveat of your way is that systemd doesn't know about your final
target until it receives "systemctl start destination.target". Since
it doesn't know about the target, units that are requested by
destination.target will not have the default dependencies applied.
For example, if your destination target WANTS hello.socket (which has
DefaultDependencies=yes), hello.socket will not be started before
socket.target.
Umut
On Fri, Jan 30, 2015 at 7:06 AM, Hoyer, Marko (ADITG/SW2)
wrote:
> Hi Alison,
>
>> -Original Message-
>> From: Alison Chaiken [mailto:ali...@she-devel.com]
>> Sent: Thursday, January 29, 2015 8:17 PM
>> To: systemd-devel@lists.freedesktop.org
>> Cc: Hoyer, Marko (ADITG/SW2)
>> Subject: Re: Support for staged startup
>>
>> Marko Hoyer asks:
>> > I'd like to realize a staged startup with systemd which is mainly
>> about:
>> > - starting up a static tree up to a final service
>> > - the only job of the final service is to kick off the start of an
>> > additional sub tree of units This kind of startup could be realized
>> > simply by adding an additional one shot service which executes:
>> > systemctl start xxx.target
>>
>> Marko, one target can already be specified as "After" another. If
>> B.target is present in one of the appropriate directories and specifies
>>
>> After=A.target
>>
>> and all the services of the final sub-tree are symlinked in a
>> B.target.wants directory, doesn't the behavior you need result? What
>> is missing?Of course, some of the units linked in B.target.wants
>> may already be started by the time A.target completes if they are part
>> of a earlier target or if they are needed by an earlier unit. To
>> suppress that behavior, you'd have to edit the individual units.
>>
>> I don't know of any use case for one unit to start another directly.
>> Is there one?
>
> 1.) Coming up with a small tree first reduces the loading time of the unit
> set (not so much important in my case)
>
> 2.) If you wanna create some dynamics between target A and target B so that
> depending on the startup situation services are already started before A or
> in another round they are delayed until A is done, you probably need to
> disconnect them from the static startup tree and pull them in dynamically at
> the desired time.
>
>>
>> -- Alison
>>
>> --
>> Alison Chaiken ali...@she-devel.com
>> 650-279-5600
>> http://{she-devel.com,exerciseforthereader.org}
>> Never underestimate the cleverness of advertisers, or mischief makers,
>> or criminals. -- Don Norman
>
> Best regards
>
> Marko Hoyer
> Software Group II (ADITG/SW2)
>
> Tel. +49 5121 49 6948
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Hi Alison,
> -Original Message-
> From: Alison Chaiken [mailto:ali...@she-devel.com]
> Sent: Thursday, January 29, 2015 8:17 PM
> To: systemd-devel@lists.freedesktop.org
> Cc: Hoyer, Marko (ADITG/SW2)
> Subject: Re: Support for staged startup
>
> Marko Hoyer asks:
> > I'd like to realize a staged startup with systemd which is mainly
> about:
> > - starting up a static tree up to a final service
> > - the only job of the final service is to kick off the start of an
> > additional sub tree of units This kind of startup could be realized
> > simply by adding an additional one shot service which executes:
> > systemctl start xxx.target
>
> Marko, one target can already be specified as "After" another. If
> B.target is present in one of the appropriate directories and specifies
>
> After=A.target
>
> and all the services of the final sub-tree are symlinked in a
> B.target.wants directory, doesn't the behavior you need result? What
> is missing?Of course, some of the units linked in B.target.wants
> may already be started by the time A.target completes if they are part
> of a earlier target or if they are needed by an earlier unit. To
> suppress that behavior, you'd have to edit the individual units.
>
> I don't know of any use case for one unit to start another directly.
> Is there one?
1.) Coming up with a small tree first reduces the loading time of the unit set
(not so much important in my case)
2.) If you wanna create some dynamics between target A and target B so that
depending on the startup situation services are already started before A or in
another round they are delayed until A is done, you probably need to disconnect
them from the static startup tree and pull them in dynamically at the desired
time.
>
> -- Alison
>
> --
> Alison Chaiken ali...@she-devel.com
> 650-279-5600
> http://{she-devel.com,exerciseforthereader.org}
> Never underestimate the cleverness of advertisers, or mischief makers,
> or criminals. -- Don Norman
Best regards
Marko Hoyer
Software Group II (ADITG/SW2)
Tel. +49 5121 49 6948
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Marko Hoyer asks:
> I'd like to realize a staged startup with systemd which is mainly about:
> - starting up a static tree up to a final service
> - the only job of the final service is to kick off the start of an additional
> sub tree of units
> This kind of startup could be realized simply by adding an additional one
> shot service which executes: systemctl start xxx.target
Marko, one target can already be specified as "After" another. If
B.target is present in one of the appropriate directories and
specifies
After=A.target
and all the services of the final sub-tree are symlinked in a
B.target.wants directory, doesn't the behavior you need result? What
is missing?Of course, some of the units linked in B.target.wants
may already be started by the time A.target completes if they are part
of a earlier target or if they are needed by an earlier unit. To
suppress that behavior, you'd have to edit the individual units.
I don't know of any use case for one unit to start another directly.
Is there one?
-- Alison
--
Alison Chaiken ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals. -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
