Linux Interview Question 1: SIGTERM Ignored SIGKILL
Linux Interview Questions · Test 1 · question 1 of 10
During a deployment you run kill 4812 to stop an old worker process. Five minutes later ps still shows PID 4812 in state S (sleeping). The application's source shows it installs a handler that logs and ignores SIGTERM.
The process holds no data you need to preserve. Which action is guaranteed to terminate it?
Show answer and explanation
Answer:
kill with no signal option sends SIGTERM, which is a *request* to terminate: a process can install a handler for it (normally to clean up and exit gracefully) or ignore it entirely, which is what this worker does. SIGKILL and SIGSTOP are the only two signals that cannot be caught, blocked, or ignored. The kernel acts on SIGKILL itself, so the process gets no chance to run cleanup code. That is why the interview answer is always "SIGTERM first, SIGKILL only if it won't exit": SIGKILL skips flushing buffers, removing lock files, and finishing in-flight work.
Option A is wrong because SIGHUP is an ordinary catchable signal. Many daemons deliberately handle it to reload their configuration instead of exiting.
Option C is wrong because the handler runs on every delivery of SIGTERM. Sending it again, or spelling it -15, changes nothing.
Option D is wrong because SIGINT, the signal Ctrl+C sends, is just as catchable as SIGTERM.
Note one real-world exception: a process stuck in uninterruptible sleep (state D) will not act on the signal until it returns from the kernel. The stem's state S rules that out here.
Reference: signal(7) - Linux manual page