Bug 1925623 - systemd mixed mode directly SIGKILLs a scope
Summary: systemd mixed mode directly SIGKILLs a scope
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.3
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: 8.0
Assignee: systemd-maint
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-05 17:52 UTC by Mrunal Patel
Modified: 2021-08-08 07:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-08 07:26:56 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.