Re: [systemd-devel] Support for staged startup

2015-02-02 Thread Lennart Poettering
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

2015-02-02 Thread Hoyer, Marko (ADITG/SW2)
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

2015-02-02 Thread Hoyer, Marko (ADITG/SW2)
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

2015-01-31 Thread Alison Chaiken
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

2015-01-30 Thread Umut Tezduyar Lindskog
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)
mho...@de.adit-jv.com 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


[systemd-devel] Support for staged startup

2015-01-29 Thread Hoyer, Marko (ADITG/SW2)
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 ...

Thx for any feedback.

Best regards

Marko Hoyer

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Support for staged startup

2015-01-29 Thread Alison Chaiken
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


Re: [systemd-devel] Support for staged startup

2015-01-29 Thread Hoyer, Marko (ADITG/SW2)
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