Every running program on a Linux system is a process, an instance with its own process ID, its own memory, and a parent that started it, and the whole system is a tree of these descending from PID 1. Understanding processes matters because almost everything you do to manage a running system, starting a service, stopping a runaway program, reloading a configuration, is ultimately an act of creating processes or sending them signals, and the tool most people reach for, kill, is widely misunderstood in a way that causes real damage.
The first thing to correct is that kill does not kill, it sends a signal, and termination is merely the default signal's effect. A signal is a small asynchronous message the kernel delivers to a process, and a process can choose how to respond to most of them. The ones worth knowing are few.
| SIGNAL | EFFECT |
|---|---|
| SIGTERM (15) | The polite request to terminate, and the default. A process can catch it, clean up, and exit gracefully. |
| SIGKILL (9) | The forced kill, which cannot be caught or ignored, the kernel destroys the process at once with no cleanup. |
| SIGHUP (1) | Originally a hangup, now commonly used to tell a daemon to reload its configuration without restarting. |
| SIGINT (2) | The interrupt sent by Ctrl C, a request to stop, catchable like SIGTERM. |
| SIGSTOP, SIGCONT | Pause a process and resume it later, the mechanism behind job control. |
The common habit of reaching straight for kill -9 is a mistake worth unlearning, because SIGKILL gives the process no chance to shut down cleanly. A well behaved program handles SIGTERM by flushing its buffers, closing its files, releasing its locks, and finishing its in flight work before exiting, and SIGKILL denies it all of that, which can leave corrupted files, stale lock files, orphaned child processes, and half written state. The correct sequence is to send SIGTERM first and give the process a moment to exit on its own, escalating to SIGKILL only when it has clearly hung and ignored the polite request. Reaching for the forced kill by reflex trades a clean shutdown for a fast one, and pays for it later in the mess left behind.
It is also worth understanding what a process can be doing when it will not die, because a process blocked in an uninterruptible state, waiting on disk or a stuck network mount, cannot even be killed until that operation returns or times out, and no signal will move it. A related curiosity is the zombie, a process that has exited but whose parent has not yet collected its exit status, so it lingers in the table as a harmless entry until it is reaped. None of this is trivia, it is the difference between an engineer who understands why a process is not responding and one who escalates to force and hopes, because managing a running system well means treating a process not as a thing you destroy but as a thing you communicate with, where the signal you choose determines whether it leaves the system clean or broken.