Linux signals and graceful process shutdown

What it means

A signal is a notification to a process. A handler is application code arranged to respond to a catchable signal, and the signal’s disposition is the response selected for it. “Graceful shutdown” describes what the application does—such as completing required work before exiting—not a property that the name SIGTERM guarantees.

Try it

Simulation: start with Signal = SIGTERM and Process installs a TERM handler? = yes. Change only Signal to SIGKILL, then inspect the result and its explanation. Use Compare with baseline to place the current result beside the documented starting result. No process is signaled. Without JavaScript, the initial example remains readable, but the controls do not operate.

The starting result is “Application can handle TERM.” Its explanation is: “A catchable SIGTERM may allow cleanup but does not promise its completion.” The result describes an available handling path, not completed cleanup.

Keep Process installs a TERM handler? = yes for the first comparison. The scene’s unblocked, non-ignored TERM assumption remains fixed; there is no delivery-time control.

Reset restores Signal = SIGTERM and Process installs a TERM handler? = yes, removes input errors and clears the comparison. It leaves your independently opened or closed FAQ answers and About this model disclosure unchanged.

How it works

A signal’s disposition determines whether the process uses a handler, ignores the signal or follows its default action. A signal mask can also block delivery of signals that permit blocking. The scene deliberately fixes TERM as unblocked and not ignored so you can isolate the effect of the handler selection.

With SIGTERM and a TERM handler installed, the application has a handling path available. That is the intermediate condition behind “Application can handle TERM.” The model does not execute a handler or evaluate its success, so it cannot turn that opportunity into a cleanup-completed result.

Keep SIGTERM selected and change Process installs a TERM handler? to no. The result is “Default termination behavior may apply.” Under the exercise’s unblocked, non-ignored TERM assumption, the process without a TERM handler has the default termination disposition. This branch is not a prediction of termination timing.

SIGKILL removes the application-handler path altogether: it cannot be caught, blocked or ignored. The important contrast is application participation versus forced termination—not safe versus instant. An installed TERM handler changes the SIGTERM branch but has no effect on the SIGKILL branch.

Worked example

This is a synthetic example, not a captured shutdown.

The calculated result is “Application can handle TERM.” The explanation is: “A catchable SIGTERM may allow cleanup but does not promise its completion.” With TERM assumed unblocked and not ignored, the installed handler makes application participation possible. No intermediate state in this model says that files were saved or that the process exited.

What changes when the condition changes

Change Signal to SIGKILL while keeping Process installs a TERM handler? = yes. The result becomes “Cannot catch this termination signal.” The explanation is: “SIGKILL cannot be caught or ignored; the process does not run its TERM handler.” The handler remains installed in the example, but it cannot intercept SIGKILL. Changing the handler selection to no would not change this result: the selected signal rules out that application cleanup path.

In practice

Use this distinction to evaluate a shutdown plan, not as instructions to signal a running process. For a Linux service you are authorized to administer, begin with a read-only preflight: identify the supervisor, confirm the intended workload and current process identity, and consult the application’s documented shutdown behavior. Record the current state and the exact workload the plan would affect.

Define the expected observation before considering a change: what would show that the intended workload stopped, and what separate evidence would show that required application work completed? A signal-sending result cannot answer both questions.

STOP if the target, authority, shutdown behavior or recovery plan is unclear. If an observed shutdown differs from the documented expectation, inspect process and supervisor state rather than escalating blindly. Any real stop or forced interruption needs a service-specific procedure, verification criteria and a recovery plan for partially completed work. Restarting a process is not proof that its data is consistent. This page provides no mutating commands or universal TERM-to-KILL sequence.

Limits and unknowns

No process is signaled, and no machine, account, filesystem or service is inspected. The selections describe a synthetic situation; they do not establish that a real process received a signal, ran a handler, exited or saved its work. Those outcomes remain unknown without observations from the actual environment.

TERM is assumed unblocked and not ignored. The scene does not model blocking, explicit ignoring, handler implementation, delivery delays, shutdown duration or supervisor recovery. In particular, “cannot catch” is not a measured promise of instant completion.

If input validation reports an error, no calculated outcome applies until you correct the input or use Reset. A valid categorical result must not be read as proof of a real shutdown.

What to carry forward

Separate the opportunity to run cleanup from evidence that cleanup completed. Choose a shutdown approach from the workload’s documented behavior, then judge the outcome from the resulting service and application state—not from the signal’s name or an attempted send.