Common signs include a process that stays visible in ps or top after SIGTERM, continued resource consumption, frozen application behavior, or error messages showing the command was not permitted. A process may also be in zombie state or uninterruptible sleep. In those cases, verify the PID, review logs, and decide whether the parent process or higher privileges are needed.
What the signal means when a Linux process ignores normal termination
A process that stays alive after SIGTERM is telling you that graceful shutdown is not completing, not that it is necessarily broken in every case. The key distinction is between a process that is still handling cleanup and one that has stopped responding to its termination path altogether. That difference usually determines whether you wait, escalate, or move straight to a stronger signal.
Normal termination should allow the process to close files, release locks, finish I/O, and exit cleanly. When that path fails, the process may still appear healthy enough to the kernel or scheduler, but from an operator perspective it has stopped behaving as expected. In practice, that often shows up as stuck application state, open handles that do not clear, or a PID that remains present after the expected shutdown window.
The most useful supporting check is whether the process is merely slow, blocked, or genuinely unresponsive. A blocked process can still be doing work in kernel space, while a truly stuck process may never return from the code path that should process termination. That is why the visible symptom matters less than the surrounding state, especially whether the process can be correlated with its parent, logs, and current system load.
States and conditions that separate a delay from a true hang
Two process states matter most in this situation: zombie and uninterruptible sleep. A zombie has already exited but still has an entry because the parent has not reaped it, so it is not “ignoring” SIGTERM in the normal sense. Uninterruptible sleep usually means the process is blocked waiting on I/O or another kernel resource, and it may not respond until the underlying wait clears.
That distinction is operationally important because the fix differs. A zombie points you toward the parent process and reaping behavior, while uninterruptible sleep points you toward storage, filesystem, network, or device-level stalls. If a process stays present in NIST Cybersecurity Framework 2.0 aligned monitoring after SIGTERM, the next question is whether the issue is lifecycle handling, blocked kernel work, or a privilege problem preventing the signal from being delivered effectively.
Permission-related errors also change the interpretation. If the command was not permitted, the process may be intact and healthy, but the operator does not have authority to signal it. That is not a termination failure by the process itself; it is an access problem. In those cases, verify the effective user, the target PID, and whether the session or supervision layer is constraining the action.
For process and credential hygiene at scale, the lifecycle and visibility lessons in NHI Lifecycle Management Guide are a useful parallel for thinking about ownership, cleanup, and stale runtime state. When shutdown fails repeatedly, the real issue is often incomplete control over the object’s lifecycle rather than a single failed kill attempt.
Risk and Threat Considerations
A process that will not terminate cleanly can become an availability problem, especially when it is holding locks, consuming resources, or blocking dependent services. The bigger risk is not just that the process remains visible, but that it keeps a bad state alive long enough to affect recovery, deployment, or incident response.
Failure mechanism: the process is blocked in a kernel wait, stuck in cleanup logic, or protected by insufficient privileges, so normal termination does not reach the point where it can exit or be reaped.
Impact: operators may see lingering resource consumption, stalled restarts, orphaned children, or a service that appears down but still retains state that interferes with remediation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Permission errors affect whether termination signals can be sent. |
| DE.CM-8 — Monitoring for Anomalous Activity | Lingering processes and stuck states are operational anomalies worth detecting. | |
| RS.AN-1 — Analysis | Investigating why a process ignores termination requires state and log analysis. | |
| Recommendation — Verify the caller’s authority before escalating to stronger termination actions. Alert on processes that remain active after expected shutdown windows. Correlate PID state, logs, and parent process behavior before remediation. | ||
| CIS Controls v8 | 8.3 — Audit Log Management | Logs help distinguish blocked, privileged, and lifecycle-related termination failures. |
| 4.1 — Establish and Maintain a Secure Configuration Process | Stalled shutdowns can reflect misconfiguration or control-plane issues. | |
| Recommendation — Retain shutdown and privilege logs needed to explain unresponsive processes. Review service and supervisor settings that affect process termination behavior. | ||
Practitioner Guidance
What to verify: confirm the exact PID, owner, state, and parent-child relationship before escalating to stronger signals. If the process is a zombie, focus on the parent; if it is in uninterruptible sleep, focus on the resource it is waiting on.
Decision rule: if SIGTERM fails but the process is not in a blocked kernel wait, move to log review and privilege validation before assuming malicious behavior or a code defect. If the process is still in D-state, the practical next step is to identify the dependency it is waiting for rather than repeatedly signaling it.
Practitioner takeaway: the most important judgment is whether you are dealing with a shutdown problem, a wait-state problem, or an authority problem, because those three conditions look similar from the outside but require very different fixes.
Related resources from NHI Mgmt Group
- What are the signs that a CVE remediation process is not keeping pace with embedded Linux releases?
- What are the signs that a Linux system may be running a stealthy shared-library implant rather than a normal preload configuration?
- What are the signs that an SBOM process is failing to support vulnerability response?
- What are the signs that an IAM matching process is failing?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
