Bug 1925623

Summary: systemd mixed mode directly SIGKILLs a scope
Product: Red Hat Enterprise Linux 8 Reporter: Mrunal Patel <mpatel>
Component: systemdAssignee: systemd-maint
Status: CLOSED WONTFIX QA Contact: Frantisek Sumsal <fsumsal>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 8.3CC: dtardon, kir, msekleta, systemd-maint-list
Target Milestone: rcKeywords: Reopened
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-08-08 07:26:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mrunal Patel 2021-02-05 17:52:41 UTC 
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)
9:45
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):
systemd 239


How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 David Tardon 2021-02-08 09:38:27 UTC 
(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.
Comment 3 Michal Sekletar 2021-02-08 14:27:50 UTC 
Sending SIGKILL mercilessly seems wrong, reopening.
Comment 5 Kir Kolyshkin 2021-02-16 16:20:32 UTC 
> 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).
Comment 7 RHEL Program Management 2021-08-08 07:26:56 UTC 
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.