Linux Tutorial / Inspect, Pause, and Stop Processes

To manage Linux processes, identify the running program, inspect its state and resource use, and send a signal only if intervention is needed. ps provides a snapshot; top refreshes the view. To end a process, first request a normal shutdown with TERM. Reserve the uncatchable KILL signal for cases in which safer steps have failed.

Distinguish processes from shell jobs

A process is an instance of a running program and has a PID (process ID). Its PPID (parent process ID) identifies its parent. A job is a unit tracked by one shell; it may contain more than one process. A job identifier such as %1 belongs to that shell's job control and is not the same as a system-wide PID.

Some processes belong to services, but not every process is a service. Before killing a service's individual process, inspect its state and logs through the service manager. This lesson focuses on observing and controlling a practice process owned by your account.

Select useful columns with ps

ps reports processes at the instant it runs. For a system-wide view, explicit columns make it easier to compare PID, parent, owner, state, elapsed time, and command. The full list can be long, so narrow it to a known PID or program when possible.

ps -eo pid,ppid,user,stat,etime,args
ps -eo pid,ppid,user,%cpu,%mem,stat,args --sort=-%cpu | head

The second example sorts by reported CPU usage and shows the first lines. CPU figures depend on how and when they are measured; one snapshot is not proof of the cause of a slowdown. The first character of STAT commonly means: R, running or runnable; S, interruptible sleep; D, usually uninterruptible sleep; T, stopped; or Z, a terminated child whose parent has not yet collected its status. Additional characters may describe other attributes.

Watch changes with top and locate candidates with pgrep

top refreshes the process list and resource figures periodically. Sorting and displayed values depend on its configuration. Press q to leave. It is useful when you need to observe a trend rather than repeatedly invoking ps.

top

pgrep can find PIDs by name; -a includes the command line. Several similarly named processes may exist, and a process can exit immediately after the search or its PID can later be reused. Never stop a process merely because a number appeared in one search result.

pgrep -a sleep

If nothing is returned, there may be no match, visibility may be restricted, or the search expression may be wrong. For observing your own test process, the PID captured by the shell in the next exercise is a clearer target.

Pause and resume your own process

Run the following in Bash. sleep 300 & starts a 300-second sleeper in the background; $! expands to the PID of the most recent background job. Do not practice these signals on another person's process or a production service. Stay in the same shell until the exercise is complete so that you retain the practice PID.

sleep 300 &
practice_pid=$!
printf 'practice PID: %s\n' "$practice_pid"
ps -p "$practice_pid" -o pid,ppid,stat,etime,args
kill -STOP "$practice_pid"
ps -p "$practice_pid" -o pid,stat,args
kill -CONT "$practice_pid"
ps -p "$practice_pid" -o pid,stat,args

The first ps should identify the intended sleep. After STOP, the state commonly begins with T; after CONT, it can return to S or another state. The exact observation depends on timing. STOP suspends execution without ending the process; CONT resumes it.

Request termination with TERM and verify it

Finish the exercise in the same shell. TERM is the default termination request and gives a program an opportunity to clean up. wait waits for this child and collects its exit status. Because a signal ended it, wait may itself return a nonzero status.

kill -TERM "$practice_pid"
wait "$practice_pid"
ps -p "$practice_pid" -o pid,stat,args

If the last ps shows only its header or reports no matching process, the practice process is normally gone. PIDs can be reused, so seeing the same number much later does not prove it is the same process. If a program handles or ignores TERM, give it time and inspect its state and logs.

kill -KILL PID gives a process no chance to handle that signal or clean itself up. It can leave a database, active write, or service in an inconsistent state. Consider it only when the identity and consequences are clear and normal termination has failed. Ordinary users cannot send signals to processes they do not own. A task in D state may not disappear immediately even after a forceful signal.

Foreground and background jobs in the shell

In Bash, command & starts a background job. jobs -l lists job numbers and PIDs tracked by the current shell, not every process on the computer or jobs in another terminal. If you suspend a foreground job with Ctrl+Z, bg %1 can resume it in the background and fg %1 can bring it to the foreground. Select the actual job number from jobs; do not assume it is always 1.

jobs -l

Starting a program in the shell background does not make it a reliable service that survives logout. It can still be affected by the session, its input and output, and signals. Use the distribution's service-management mechanism for a server process that needs continuous management.

A diagnosis sequence for a troublesome process

1. Use ps or pgrep to confirm PID, command, owner, and parent. Do not infer identity from a similar name.
2. Use top and relevant logs to determine whether resource use persists, the task is merely waiting, or an actual error exists.
3. Find out whether a service manager owns it. If so, inspect the service state and logs before manipulating one child process.
4. If a process you own must stop, request TERM and allow time for cleanup. Escalate only if necessary.
5. Check again with ps, then investigate restarts, recurrence, and the underlying cause.

Official references

The ps(1) manual defines its fields and state codes. See the pgrep(1) manual for search options and the kill(1) manual for signals. The GNU Bash job-control documentation covers job numbers, fg, and bg.