Bug 1530556
Summary: | systemd fails to kill process in d-state and runs additional process in systemctl restart | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Yaniv Bronhaim <ybronhei> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.4 | CC: | danken, kwalker, mgoldboi, mperina, nsoffer, systemd-maint-list |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-02-14 18:20:01 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
Yaniv Bronhaim
2018-01-03 10:40:02 UTC
Back in my sysadmin days, I think I have dealt with similar situations and a process in such state cannot be killed from userspace, so, to be honest, I have no idea what should be a correct approach here. Hi Lukas, Indeed the process stays in this state until the connection returns. This bugzilla is about not running new instance of the daemon on systemctl restart, when the old pid of the same daemon is hanged or failed to terminate. (In reply to Lukáš Nykrýn from comment #2) > Back in my sysadmin days, I think I have dealt with similar situations and a > process in such state cannot be killed from userspace, so, to be honest, I > have no idea what should be a correct approach here. When unsure, it is advisable to take the safe option, of considering failure to stop the old service as an unrecoverable error. That is basically what the kernel does - if it cannot cleanly stop a process, it does not. It keeps it in D state. Depending on the specific service, running it twice can lead to a horrible data corruption. Some services may be harmless, so they can ask to be restarted even if in D state. In any case, this is not relevant for rhel-7.5.0. Based on the feedback in comment 2, and the further discussion, I am inclined to close this as WONTFIX. Has the team encountered any further instances of this behaviour? There have been quite a few changes in the kernel to allow processes to not sit in TASK_UNINTERRUPTIBLE. Instead, many processes sit within TASK_WAKEKILL, which means that the SIGKILL will be acted upon. I would believe that a good deal of the codepaths in the kernel that could result in the processes being completely unresponsive to a SIGKILL have been dealt with at this point. Does this team see any incidents or common use-cases where this assumption is incorrect? I do not how prevalent this bug is. Maybe Martin knows. What I do know is that as long as the possibility exists, there would be a customer somewhere loosing data due to it. If systemd promises to enforce no more than a single instance of a running daemon, it should do just that. After monitoring the discussion for an extended period of time, I am unable to find any common instances where this type of failure is encountered. At least not within more modern kernel versions and the ever-increasing prevalence of the TASK_WAKEKILL state in the kernel. In addition, when Red Hat shipped 7.7 on Aug 6, 2019 Red Hat Enterprise Linux 7 entered Maintenance Support 1 Phase. https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_1_Phase That means only "Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released". This BZ does not appear to meet Maintenance Support 1 Phase criteria so is being closed WONTFIX. If this is critical for your environment please open a case in the Red Hat Customer Portal, https://access.redhat.com, provide a thorough business justification and ask that the BZ be re-opened for consideration in the next minor release. |