How do you find and stop a process in Linux, and what is the difference between SIGTERM and SIGKILL?
Use ps or top to find the process ID, then kill to send it a signal. SIGTERM (15, the default) politely asks the process to exit so it can clean up, while SIGKILL (9) makes the kernel end it immediately and cannot be caught or ignored.
Explain it simply
Imagine the canteen is closing. The manager first announces, "We are closing in ten minutes, please finish up." People finish their chai, pay and leave properly. That is SIGTERM. If someone still refuses, security walks them out immediately, plate half-eaten. That is SIGKILL.
Every running program in Linux is a process with a number called the PID. A signal is a small message the kernel delivers to a process. Most signals can be handled by the program in its own way. SIGKILL and SIGSTOP are special: the program never gets a say.
Example
Find the process:
ps aux | grep '[n]ode'
pgrep -a noderavi 4812 2.3 1.8 1093420 148220 ? Sl 10:02 0:41 node server.js
4812 node server.js(Writing [n]ode stops grep from matching its own command line.)
Stop it, gently first:
kill 4812 # sends SIGTERM (15)
sleep 5
kill -0 4812 && kill -9 4812 # still alive? then SIGKILLkill -0 sends no signal; it only checks whether the process exists. Other handy tools: top or htop for a live view sorted by CPU, pkill -f server.js to signal by name, and kill -l to list all signals.
How it works
Common signals:
| Signal | Number | Meaning | Can be caught? |
|---|---|---|---|
| SIGHUP | 1 | terminal closed; many daemons reload config on it | yes |
| SIGINT | 2 | Ctrl+C | yes |
| SIGKILL | 9 | kill now | no |
| SIGTERM | 15 | please terminate (default for kill) | yes |
| SIGSTOP | 19 on x86 Linux | pause | no |
When a process gets SIGTERM, its handler can close database connections, flush logs and delete temp files before exiting. SIGKILL skips all of that; the kernel just tears the process down and reclaims its memory. Data still in the program's buffers is lost.
Real-world use
docker stopand Kubernetes send SIGTERM, wait for a grace period, then send SIGKILL. Servers should handle SIGTERM to finish in-flight requests.systemctl stopfollows the same pattern.- Nginx reloads its configuration on SIGHUP without dropping connections.
Common mistakes
- Reaching for
kill -9first. The program cannot save its state, and you may leave lock files, half-written files or orphaned child processes behind. - Assuming SIGKILL always works instantly. A process in uninterruptible sleep (state
D, usually waiting on disk or NFS I/O) will only die once that I/O returns. - Trying to kill a zombie. It is already dead; its parent must collect it.
What to say in the interview
"I find the PID with ps aux, pgrep or top, then use kill. By default kill sends SIGTERM, which asks the process to exit and lets it run a handler to clean up. If it does not exit after a reasonable wait, I send SIGKILL with kill -9, which the kernel enforces and the process cannot catch, block or ignore, so no cleanup happens. That is why Docker and Kubernetes send SIGTERM first and only send SIGKILL after a grace period."
Follow-up questions
- What is a zombie process and how do you get rid of it?
- What is an orphan process, and who adopts it?
- Why can a process in
Dstate not be killed? - What does
nohupdo?
Go deeper
Read these once the basics above feel easy.
Zombies. When a child exits, the kernel keeps a small entry (its PID and exit status) until the parent reads it with wait(). Until then the child shows as Z or <defunct> in ps. Killing the zombie does nothing. You fix it by making the parent call wait() (often in a SIGCHLD handler) or by killing the parent; the zombie is then re-parented to init (PID 1) or a subreaper, which reaps it.
PID 1 in containers. The process running as PID 1 in a container gets special treatment: signals it has not installed a handler for are ignored, so a plain kill with SIGTERM may do nothing. This is why images use small init programs like tini, or the app must handle SIGTERM itself.
Process groups. Ctrl+C sends SIGINT to the whole foreground process group, not just one PID. kill -TERM -1234 (a negative number) signals every process in group 1234, which is how you stop a pipeline or a script together with its children.