Skip to main content
STOPSIGNAL should not use signals that prevent graceful shutdown.

Description

STOPSIGNAL tells the container runtime which signal to send when stopping the container. Using SIGKILL or SIGSTOP defeats the purpose of STOPSIGNAL:
  • SIGKILL (signal 9) cannot be caught, blocked, or ignored. The process is terminated immediately with no opportunity to flush data, close connections, or perform any cleanup. The container runtime will send SIGKILL automatically after the stop timeout anyway, so setting it as the STOPSIGNAL skips the graceful shutdown window entirely.
  • SIGSTOP (signal 19) suspends the process instead of terminating it. The container will not exit, and the runtime will eventually escalate to SIGKILL after the stop timeout.
This rule also detects non-canonical forms such as numeric signal values (9, 19), signals without the SIG prefix (KILL, STOP), and lowercase variants (sigkill). Environment variable references (e.g. STOPSIGNAL $MY_SIGNAL) are skipped because the signal value cannot be determined statically. Windows stages are skipped because STOPSIGNAL has no effect on Windows containers — POSIX signals are not delivered to Windows processes.

References

Examples

Bad

Good

Auto-fix

The suggested fix replaces the ungraceful signal with SIGTERM, which is the standard graceful stop signal for most processes:
The fix uses FixSuggestion safety because replacing the signal changes container stop behavior. Review the replacement to ensure SIGTERM is appropriate for your daemon. Some daemons prefer different signals for graceful shutdown (e.g. SIGQUIT for nginx, SIGINT for PostgreSQL).

Configuration