Description of problem:
We set KillMode to mixed for container scopes running in OpenShift, but on systemctl stop, the main process inside the scope is getting a SIGKILL instead of SIGTERM, wait and then SIGKILL.
Red Hat Enterprise Linux CoreOS 47.83.202102050944-0 (Ootpa)
Linux test1-z6sl7-master-2 4.18.0-240.10.1.el8_3.x86_64 #1 SMP Wed Dec 16 03:30:52 EST 2020 x86_64 x86_64 x86_64 GNU/Linux
Version-Release number of selected component (if applicable):
Steps to Reproduce:
(In reply to Mrunal Patel from comment #0)
> Description of problem:
> We set KillMode to mixed for container scopes running in OpenShift, but on
> systemctl stop, the main process inside the scope is getting a SIGKILL
> instead of SIGTERM, wait and then SIGKILL.
Scopes have no main process. Only services do. Therefore the observed behavior matches what the man page says.
Sending SIGKILL mercilessly seems wrong, reopening.
> Scopes have no main process. Only services do. Therefore the observed behavior matches what the man page says.
If you mean systemd.scope(5) man page, indeed it says there is no main process in the scope
> Note that, unlike service units, scope units have no "main" process: all processes in the scope are equivalent. The lifecycle of the scope unit is thus not bound to the lifetime of
> one specific process, but to the existence of at least one process in the scope. This also means that the exit statuses of these processes are not relevant for the scope unit failure
> state. Scope units may still enter a failure state, for example due to resource exhaustion or stop timeouts being reached, but not due to programs inside of them terminating
> uncleanly. Since processes managed as scope units generally remain children of the original process that forked them off, it is also the job of that process to collect their exit
> statuses and act on them as needed.
but says nothing about KillMode differences.
Oh, ok, systemd.kill(5) says
> If set to mixed, the SIGTERM signal (see below) is sent to the main process while the subsequent SIGKILL signal (see below) is sent to all remaining processes of
> the unit's control group.
which, together with the knowledge that scopes have no main process, means that SIGTERM is never sent.
I see two problems with this
1. This knowledge is split between two pieces of documentation.
2. The same systemd.kill(5) page later says
> Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal= or RestartKillSignal=).
which sorf of ensures we'll get SIGTERM first (it is not defined what "processes" are).
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.