[systemd-devel] after=user.slice not enforced

[Lennart Poettering]

On Wed, 23.11.16 09:14, Cédric BRINER (cedric.briner at unige.ch) wrote:

> 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
> *children*. That way we could ensure that our stop services'
> commmand is launched as the first ever before any kill ?

No it does not. Unit dependencies apply to each unit individually and
they do not propagate

> 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.

You cannot. Either systemd execs your daemon and then also stops
it. Or you exec it, and then you stop it. There's no concept for
making systemd adopt foreign services...

(Not sure I grok what you want to do, but do note that "systemd-run"
may be used to invoke binaries as services without prepping a unit
file for it, instead providing all the definitions on the command
line)

systemd provides a clean, well-defined execution environment to every
service, as such it really doesn't permit sysv-like behaviour that
daemon processes are forked off random user processes.

Lennart

-- 
Lennart Poettering, Red Hat