On Thu, 24 Nov 2016, Kai Krakow wrote:
Am Wed, 23 Nov 2016 09:14:34 +0100
schrieb Cédric BRINER <cedric.bri...@unige.ch>:
For the context, we are trying to stop a daemon launched by a user...
sapRunning service contains a "After=user.slice". But at the
shutdown, a process (write-sysv-test.pl) running in user.slice is
killed before the end of the sapRunning's stop.
Slices are a concept for resource management, and that's what they
should be used for. Do not user them for anything else, such as
In systemd shutdown ordering is the inverse of start-up ordering,
and After= and Before= declare the latter. This means that if your
service has After=user.slice, this means at shutdown your service
will be stopped first and user.slice second.
Thanks for the clarification.
But this has not the expected impact. We were wishing with the
"After=user.slice", that the stop sapRunning will occur before any
user commands are stopped.
Does using "After=user.slice" propagate also on all the *childs*. That
way we could ensure that our stop services' commmand is launched as
the first ever before any kill ?
The question still remain for us, how can we do to have a daemon
launched by hand, that can be handled by systemd for its stopping.
I think you could maybe use targets as synchronizations points... Maybe
make a target that starts after multi-user.target and requires it. Then
put your service as wanted by this new target (maybe also using after
and requires), let's call it sap-started.target. Then make that the
default target at boot.
That way, on shutdown, it should first stop and wait for
sap-started.target, and only then pull down the rest of the system.
Simply ordering target units won't help. At boot, systemd does not wait
for the first target to be reached before considering starting the units
wanted by the second target. Similarly, at shutdown it will not wait for
the second group of units to be stopped before stopping the first group of
units -- indeed, the target units themselves could be stopped almost
What you can do is have something like this:
Normally, this unit would be Before=multi-user.target (this is an
implicit dependency added when a target Wants= something).
By adding an explicit After=multi-user.target dependency, however, you can
A unit with this dependency will be "started late" and "stopped early".
However, this doesn't really do anything to order it with respect to user
sessions. As described elsewhere in this thread, there's no clean way to
systemd-devel mailing list