Processes & Signals

Published on:

Most important commands to remember

  • ps — inspect a process.
  • kill -SIGNAL PID — send a signal to a process. The signal determines what happens.

Commands and flags

These are the commands used in the short example below. PID means the process ID you want to inspect or control.

Command Meaning
ps -p "$process_pid" -o pid,stat,comm -p selects the saved PID; -o chooses the columns: process ID, state, and program name.
kill -STOP "$process_pid" Pause the process.
kill -CONT "$process_pid" Resume the paused process.
kill -TERM "$process_pid" Request termination. The application can handle the signal to clean up before exiting.
sleep 300 Create a simple process that waits for 300 seconds (five minutes).

The example also uses Bash syntax: & starts a command in the background, $! holds its PID, and process_pid=$! saves it. "$process_pid" inserts that saved value into a command.

The concepts that matter

1. A program is code; a process is a running instance

A program exists as files on disk. Starting it creates a process, with memory and access to resources such as files and network connections. Your shell, a web server, and a database run as processes. One application can have several processes.

Processes are started by something: your shell, another application, or a service manager. They can keep running after startup, waiting for work.

2. A PID identifies a process

Linux assigns each process a process ID (PID). You use it to inspect or signal that particular process. Starting the same program twice creates separate processes with separate PIDs.

A PID identifies a process while it exists. It is not a permanent application identifier; Linux can reuse the number later.

3. Existing does not mean working

A process can be executing, waiting, or stopped. In the STAT column of ps, focus on the first letter:

  • R — running or ready to run: executing or waiting for CPU time.
  • S — sleeping: waiting for an event, such as incoming work or a timer. This is often normal.
  • T — stopped: execution is suspended; a continue signal can resume it.

These are the states to remember first, not every possible Linux state. A process being present does not prove the application is healthy. A server can exist without answering requests.

4. Signals control or notify a process

kill sends signals; it does not always terminate. SIGSTOP pauses a process without removing it. SIGCONT resumes it. SIGTERM requests termination.

An application can handle SIGTERM to finish work and release resources. That cleanup must be implemented by the application. SIGKILL, by contrast, forces termination without letting the application handle the signal. Remember the distinction before reaching for forced termination.

One small example

Optional: use one Bash terminal on Linux. No administrator access is needed. Run these lines one at a time:

sleep 300 &
process_pid=$!
ps -p "$process_pid" -o pid,stat,comm
kill -STOP "$process_pid"
kill -CONT "$process_pid"
kill -TERM "$process_pid"

The first two lines create a background process and save its PID. ps should show its ID, usually state S, and program name sleep. The final three commands pause it, resume it, and request its termination. Successful signal commands normally print nothing; Bash may report a job-state change.

The final line ends this example’s process. If you leave it stopped, resume it before requesting termination. If it has already finished, “No such process” is expected; do not replace its PID with an unrelated one.

Keep this idea: find the process, inspect its state, then choose the signal that matches your intent.