[systemd-devel] Allow stop jobs to be killed during shutdown

[Andrey Borzenkov]

В Wed, 5 Feb 2014 00:10:51 +0100
Lennart Poettering <lennart at poettering.net> пишет:

> On Wed, 29.01.14 19:29, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
> 
> > > Thanks for tracking this done, this really sounds like you nailed the
> > > problem. Now, how to fix it?
> > > 
> > > Hmm, so, I would claim this is a shortcoming of
> > > KillMode=control-group, which is the default for everything. There has
> > > been an item on the TODO list to maybe introduce a KillMode=mixed
> > > setting, which would send SIGTERM only to the main process, and the
> > > SIGKILL later on to all processes. I am pretty sure that this would
> > > solve the issue at hand quite nicely here, because the systemd user
> > > instance would get a nice chance to clean up its own act, before the
> > > systemd system instance would make tabula rasa...
> > > 
> > 
> > I still favor alternative approach - let systemd wait for main PID
> > to exit after ExecStop instead. This is functionally equivalent to the
> > above with slight advantages
> 
> I am really not convinced that ExecStop= should be allowed to be
> asynchronous. (Which is what you suggest we do, right?)

Yes.

>                                                         In fact, it's
> already problem enough that we pretend we allow ExecReload= to be
> asynchronous like that... It's a question of allowing bad code
> through...

I do not suggest "send it a singnal and pray for it". You send a signal
(or whatever) and wait for MAINPID to exit. MAINPID is *the* service for
systemd. Service exists while it runs; service is stopped when it
exits. I do not understand what is bad about it, sorry.

>             Either people let us shutdown a service, or they do it
> themselves, but allowing a crappy (asynchronous) shutdown routine sounds
> wrong to me...
> 

It is synchronous for systemd - it waits until MAINPID exits. Not every
service has natural synchronous stop implementation - actually, I
suspect that most of them do not and simply use busy loop waiting for
the same MAINPID. But we already have PID 1 whose job is to wait for
other processes to exist and it does its job rather well. Why not rely
on it? 

> At the hackfest in BRU I have now implemented KillMode=mixed, which
> should fixed the issue mostly... Could you test, please?

Sure it works, but it does exactly the same - it implements
asynchronous service stop without having benefits of reaping leftover
processes early.