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

[Tom Gundersen]

Hi Andrey,

On Sun, Jan 26, 2014 at 4:21 PM, Andrey Borzenkov <arvidjaar at gmail.com> wrote:
>> I'm almost sure it is. cg_kill_recursive is in no way atomic, so it can
>> easily hit new process that was spawned since service stop had been
>> initiated.

Thanks for debugging this!

>> Unfortunately, setting KillMode=process is not allowed:
>>
>> Jan 26 17:12:30 linux-1a7f systemd[1]: user at 0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing.
>>
>> Probably user at .service should be exempt from this rule. It is supposed
>> to handle all services started by it itself, it *is* service manager
>> after all?

I don't think we want any processes to survive the exit of
user at .service, so KillMode=process feels wrong. However, isn't the
problem that we are going into the "kill control-group" mode too soon,
before user at .serivce has had a chance of cleaning itself up
gracefully?

> I rebuilt systemd without this restriction, set KillMode=process for
> user at .service and this fixed things here.
>
> So there are two problems associated with user instance.
>
> 1. Using KillMode=control-group is wrong. Each service managed by user
> instance has own requirements how it is stopped. Just sending everything
> SIGTERM without even trying service ExecStop first is obviously
> incorrect.

I guess what we want is to first send SIGTERM only to the systemd
--user process, and only after a timeout start sending SIGTERM to all
the processes in the control group? I.e., wouldn't a ExecStop entry in
user at .service give us the required timeout?

> 2. user at .service has single timeout, but it manages unknown in advance
> number of services each needing unknown timeout. While having some
> capping to total timeout looks sensible, only user itself may estimate
> the value. But service user at .system is system-level service which use
> cannot configure ...

I think it really makes sense to have a system-wide timeout on these
things (possibly a high one), we don't want the user to delay things
without limit. The user already has the possibility of putting their
own limits if they want to (but they must of course be shorter than
the system-wide one).

Cheers,

Tom