Linux Process Management

What Is a Process?

A process is a running instance of a program. When you open a shell, start a web server, or run a script, Linux creates processes to do that work.

Process management is a core Linux skill because troubleshooting often comes down to answering questions like:

• what is running?
• who started it?
• how much CPU or memory is it using?
• is it stuck?
• how can I stop it safely?

Listing Processes with ps

The ps command shows process snapshots.

ps
ps aux
ps -ef

Commonly used forms:

• ps aux shows a broad list with CPU, memory, and command info
• ps -ef shows parent-child relationships and full commands in a format many admins like

Example:

ps aux | grep nginx

This helps you see running Nginx processes.

Watching Processes Live with top and htop

top shows a live updating view of system activity.

top

You can inspect CPU usage, memory consumption, load, and the busiest processes.

htop provides a friendlier interactive view if installed.

htop

Many servers do not include htop by default, so you should know top first.

Tip: top is usually available everywhere, which makes it a dependable first troubleshooting tool.

Stopping Processes with kill

Every process has a PID or process ID. Use kill to send signals to it.

kill 1234
kill -15 1234
kill -9 1234

Common signals:

• 15 or SIGTERM: polite request to stop
• 9 or SIGKILL: forceful termination

Prefer SIGTERM first so the process has a chance to clean up.

Note: SIGKILL cannot be ignored, but it also does not let the process shut down gracefully.

Process Priority with nice and renice

Linux lets you influence scheduling priority with nice values. Lower nice values mean higher priority; higher nice values mean lower priority.

Start a command with a custom nice value:

nice -n 10 backup-script.sh

Change an existing process:

renice 5 -p 1234

This is useful when you want background jobs to be less disruptive to interactive or production workloads.

Jobs, Backgrounding, and Foreground Control

In a shell session, you can manage jobs directly.

Start a process in the background:

long-running-command &

List shell jobs:

jobs

Move a stopped job to the background:

bg %1

Bring a job to the foreground:

fg %1

This is useful during interactive work when you want to keep a task running without blocking your terminal.

Keeping Processes Alive with nohup

Normally, a process tied to your shell may stop when you disconnect. nohup helps keep it alive.

nohup ./sync-data.sh > sync.log 2>&1 &

This is handy for long-running tasks over SSH.

nohup ignores the hangup signal and, combined with &, lets the command continue in the background.

Process States

Linux processes can exist in different states. You may see letters like these in process listings:

• R = running or runnable
• S = sleeping
• D = uninterruptible sleep, often waiting on I/O
• T = stopped
• Z = zombie

A zombie process has finished execution but still has an entry because its parent has not collected its exit status yet.

A Practical Troubleshooting Example

Suppose an app is slow and users report timeouts.

A simple investigation could be:

top
ps aux | grep myapp
ps -ef | grep myapp

If one backup process is using too much CPU, you might lower its priority:

renice 15 -p 2481

If a worker is frozen and not responding to normal shutdown logic, you might send SIGTERM, then escalate if required:

kill 2481
kill -9 2481

Best Practices

• inspect before killing
• prefer graceful signals first
• use top to understand the system before acting
• background carefully and know which jobs belong to your shell
• use nohup when disconnects would otherwise stop important tasks

Test Your Understanding

Let's see how well you understood the concepts! These exercises will help reinforce what you just learned.

Exercise 1: Choosing the first stop signal

Question: When a process is misbehaving, which signal should you normally try before using SIGKILL?

Exercise 2: Tracking background jobs

Question: What does the jobs command show?

Exercise 3: Surviving shell disconnects

Scenario: You launch a long sync over SSH and do not want it to die when your terminal closes.

Question: Why is nohup ./sync-data.sh > sync.log 2>&1 & useful here?