[systemd-devel] after=user.slice not enforced
Kai Krakow
hurikhan77 at gmail.com
Thu Nov 24 22:52:24 UTC 2016
Am Wed, 23 Nov 2016 09:14:34 +0100
schrieb Cédric BRINER <cedric.briner at unige.ch>:
> Hi,
>
> For the context, we are trying to stop a daemon launched by a user...
>
> >> Hi,
> >>
> >> 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
> > ordering purposes.
> >
> > 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.
But what's the purpose of stopping user processes only after this
service was stopped? This does make no sense to me. I'd instead define
proper dependencies.
--
Regards,
Kai
Replies to list-only preferred.
More information about the systemd-devel
mailing list