If you cannot see which programmes are running on your server, you are flying blind — a runaway process could eat all your memory and crash the system before you even know something is wrong. That is why every Linux system administrator must master process management and monitoring: the ability to view, control, and troubleshoot the programmes that make your computer do its job. For the LFCS exam, you need to prove you can identify misbehaving processes, prioritise critical work, and safely stop tasks that have gone rogue, all from the command line.
Jump to a section
A simple way to picture Process Management and Monitoring
A busy restaurant kitchen during the dinner rush. The head chef stands at the pass, holding a stack of new order tickets, each one a demand for a specific dish — a steak medium-rare, a vegan curry, a side of chips.
The chef does not cook everything herself. Instead, she reads each ticket and shouts the order to the right station: the grill cook starts the steak, the sauce chef heats the curry. Each cook is a process — a running instance of a programme — with its own task, its own resources (ingredients, a burner), and its own status: actively searing, waiting for an oven to be free, or finished and waiting for plating.
The chef constantly monitors the kitchen. She sees the grill cook is overwhelmed with three steak orders, so she calls over a prep cook to lend a hand — that is adjusting priority. She checks the ticket on the fryer that has been waiting ten minutes — that is inspecting a process that seems stuck. If a cook burns a sauce and has to start over, she kills that task and reassigns it.
Just so in Linux: the operating system is the head chef. Every programme you run — a text editor, a web server, a system update — is a process. The kernel (the core of the OS) manages who gets CPU time, memory, and access to disks. If a process hangs, the administrator must identify it and kill it, or reprioritise it so the important work gets done first. The kitchen never stops; neither does a Linux server.
When you double-click an application on your phone, the operating system loads its code into memory and starts executing its instructions. That running instance is called a process. Every programme you launch — from a web browser to a background system service — becomes one or more processes.
In Linux, the kernel (the absolute core of the operating system) is responsible for creating, scheduling, and terminating every process. The kernel assigns each process a unique identifier called a PID (Process ID). Think of the PID as a passport number: it is how the system refers to that specific running programme.
Processes exist in one of several states at any moment. The most common states are:
Running: the process is currently being executed by the CPU (the processor of your computer).
Sleeping: the process is waiting for something, such as data from the hard disk or input from the keyboard. It is not using CPU time, but it is still alive in memory.
Stopped: the process has been paused, often by a signal from the administrator. It is not executing and cannot continue until it receives a signal to resume.
Zombie: a child process that has finished executing but whose parent process has not yet read its exit status. Zombie processes use almost no resources, but a buildup of them indicates a software bug.
You can view all running processes using the ps command (short for 'process status'). The most common invocation is 'ps aux', which shows every process on the system with details such as the user who owns it, the percentage of CPU and memory it is consuming, and how long it has been running. Another powerful tool is 'top', which gives a live, updating view of processes sorted by resource usage. The 'htop' command is a more user-friendly version of 'top' with colour coding and mouse support.
Every process belongs to a user. When you log in and run a programme, it runs with your user ID. Some processes, called daemons, run in the background and start automatically when the system boots. Daemons typically run as the 'root' user (the system administrator account) or a dedicated service user. For example, the SSH server (sshd) is a daemon that waits for remote login attempts.
Processes are organised in a tree. When you launch a programme from your shell (the command-line interface), that programme becomes a child process of the shell. The first process started by the kernel at boot time is called 'init' (PID 1). The init process is the ancestor of every other process on the system. On modern Linux distributions, init is usually replaced by 'systemd', which manages services and their dependencies.
To control processes, you send them signals. A signal is a simple message to a process telling it to do something. The most common signals are:
SIGTERM (signal 15): politely asks the process to terminate. The process can clean up its files and shut down gracefully.
SIGKILL (signal 9): forcefully kills the process. The process cannot ignore this signal; it is eliminated immediately. Use this only when a process refuses to respond to SIGTERM.
SIGHUP (signal 1): tells a process to reload its configuration files without stopping entirely. This is commonly used for daemons after you change their settings.
SIGSTOP (signal 19): pauses a process. It does not terminate it; it just freezes its execution until you send SIGCONT (signal 18) to resume it.
You send signals using the 'kill' command. Despite its name, 'kill' can send any signal, not just termination signals. For example, 'kill -HUP 1234' sends the SIGHUP signal to the process with PID 1234.
Process prioritisation is handled by the 'nice' value. The 'nice' value ranges from -20 (highest priority) to +19 (lowest priority). A process with a lower nice value gets more CPU time. By default, processes start with a nice value of 0. A regular user can only increase the nice value (make the process more 'nice' to others), while the root user can lower it (give the process higher priority). You can start a programme with a specific nice value using 'nice -n 10 command', and you can change the priority of an already running process with 'renice'.
Why does this matter? On a busy server, you might have dozens of processes competing for the CPU. A web server must respond to user requests quickly, while a background backup job can take its time. By adjusting nice values, you ensure critical services get the CPU time they need. Monitoring tools like 'top' show you exactly which processes are consuming the most resources, so you can spot memory leaks, runaway CPU usage, or stuck processes that need to be killed.
In summary, process management and monitoring is the skill of using command-line tools (ps, top, kill, nice, renice) to inspect the state of your system, identify problematic programmes, and take corrective action. Without these skills, you cannot keep a Linux server stable, responsive, and secure.
Identify Misbehaving Processes
Run 'top' to see a live list of processes sorted by CPU usage. Look for any process consuming more than its expected share of CPU or memory. Note its PID from the first column. This is your starting point: you cannot manage what you cannot see.
Send a Graceful Termination Signal
Use 'kill <PID>' to send SIGTERM (signal 15). This asks the process to shut down cleanly, saving any open files and releasing resources properly. Wait a few seconds and check 'top' again to see if the process disappeared. This is the safest way to stop a process.
Escalate to a Forceful Kill
If the process is still running after SIGTERM, it is stuck or ignoring the signal. Use 'kill -9 <PID>' to send SIGKILL. This immediately terminates the process without giving it a chance to clean up. Use this sparingly, as data loss can occur, but it is necessary for unresponsive processes.
Adjust Process Priority with renice
For a process that is critical (like a web server) but is losing CPU time to a batch job, use 'sudo renice -n -5 -p <PID>' to lower the nice value (increase priority). Only root can set negative values. This ensures important services get CPU time first.
Start a Long-Running Process in the Background
When you need to run a script that takes hours, use 'nohup ./script.sh &'. The 'nohup' command prevents the process from being terminated when you log out, and the '&' runs it in the background. You can close your SSH session and the script continues.
You are the sole IT administrator for a small e-commerce company that runs its online store on a single Linux server. It is the week before Black Friday, and you need to ensure the server can handle a surge in traffic. One afternoon, the company CEO calls you in a panic: the website has become extremely slow, and customers are complaining.
You immediately SSH into the server (Secure Shell — a protocol for securely connecting to a remote Linux machine). Your first step is to run 'top' to see what is happening. The output shows that a process called 'backup-script.pl' is using 95% of the CPU. This is an automated backup process that runs daily but is supposed to run at 2 AM, not during business hours. Someone scheduled it incorrectly.
You note the PID of the runaway backup process — let us say it is 4713. You decide you cannot let it keep slowing down the website. You first send a polite termination request: 'kill 4713'. This sends SIGTERM. After a few seconds, you check 'top' again; the process is still there, still using CPU. The backup script is ignoring the polite request.
You now send SIGKILL: 'kill -9 4713'. The process disappears immediately from 'top'. The website speeds up within seconds. The CEO is relieved.
But you are not done. You want to prevent this from happening again. You investigate the cron job (a scheduled task system) that launched the backup. You find it is scheduled to run at 10 AM instead of 2 AM. You correct the schedule.
Later that week, you want to ensure the web server (Apache or Nginx) always has enough CPU priority over other non-critical tasks. You check the nice value of the web server process using 'ps -eo pid,ni,cmd | grep apache'. You see it is running at nice 0. You decide to give it a slight priority boost: 'sudo renice -n -5 -p $(pgrep apache2)'. Now the web server has a higher chance of getting CPU time when the system is under load.
During Black Friday, you keep a terminal window open running 'htop' in 'tree' view so you can see how processes relate to each other. You notice that a PHP script handling customer orders is spawning many child processes that are not cleaning up properly. You configure the PHP-FPM service to limit the number of simultaneous workers.
At the end of the day, you review the system logs for any processes that have crashed. You use 'journalctl -u nginx.service' to see the logs for the Nginx service. You find evidence of a memory leak in a custom module. You file a bug report with the development team.
A few months later, you apply for a new job. The interviewer asks you to demonstrate how you would find a process eating too much memory and kill it if it is unresponsive. You explain the steps: use 'top' to identify the process, note its PID, try SIGTERM, and if that fails, use SIGKILL. You explain how to use 'renice' to deprioritise a batch processing job that should not interfere with interactive users. You pass the interview.
This is what real IT work looks like: spotting the troublemaker, deciding the right signal, and fixing the root cause so it does not happen again.
The LFCS exam tests your ability to manage and monitor processes from the command line. You will not be asked to write code — you will be asked to type the correct command with the correct options in a simulated terminal environment.
Here are the exact concepts they love to test:
The 'ps' command with various options. You must know that 'ps aux' shows all processes for all users. The exam may ask: 'Which command shows all processes running on the system?' The answer is 'ps aux'. They may also test 'ps -ef' as an alternative. Know both.
The 'top' command for real-time monitoring. You need to know that typing 'q' exits 'top', and that pressing 'k' while in 'top' lets you kill a process by PID.
The 'kill' command and signal numbers. You must memorise that SIGTERM is signal 15 and SIGKILL is signal 9. A typical question: 'What signal does 'kill -9' send?' Answer: SIGKILL.
The 'nice' and 'renice' commands. You need to know that nice values range from -20 to 19, and that only root can set negative nice values. A question might say: 'You want to start a programme with the lowest possible priority. What command do you use?' Answer: 'nice -n 19 <command>'.
Process states: 'R' for running, 'S' for sleeping, 'T' for stopped, 'Z' for zombie. They may show you the output of 'ps' and ask what a particular state letter means.
The 'killall' and 'pkill' commands: these let you kill processes by name rather than PID. The exam may ask: 'Which command kills all processes named 'firefox'?' Answer: 'killall firefox'.
The 'pgrep' and 'pkill' commands: 'pgrep' finds PIDs by name, 'pkill' sends signals by name.
Backgrounding and foregrounding processes: 'bg' puts a stopped or background job into the background, 'fg' brings it to the foreground. The 'jobs' command lists background jobs.
The 'nohup' command: used to run a process that continues even after you log out.
The '&' operator: placing an ampersand after a command runs it in the background.
Common traps set by the exam:
They might ask you to kill a process, and the PID shown is a child process. If you kill a parent process, the children may become orphaned and be adopted by init. Know the difference between killing a parent and a child.
They might test you on the 'pstree' command, which shows the process hierarchy as a tree.
They might give you a zombie process scenario and ask what to do. The answer: you cannot kill a zombie directly; you must kill its parent process so that the zombie is reaped (cleaned up) by init.
They might ask about the 'uptime' command, which shows how long the system has been running and the load average. Load average is the average number of processes waiting to run over 1, 5, and 15 minutes. A high load average indicates a busy system.
They might ask about 'systemd' and the 'systemctl' command for managing services. Even though systemd is a service manager, it is also a process manager (PID 1). You may need to know how to restart a service using 'systemctl restart servicename'.
Key definitions to memorise verbatim:
PID: Process ID, a unique number assigned to each running process.
PPID: Parent Process ID, the PID of the process that created this process.
TTY: The terminal (teletype) associated with a process. '?' means no terminal.
TIME: Total accumulated CPU time used by the process.
COMMAND: The command that launched the process.
To pass the process management questions, practise typing these commands repeatedly until they become automatic. Use a Linux virtual machine and run 'ps', 'top', 'kill' on harmless test processes. Repetition is the only way to build speed and accuracy for the exam.
Every running programme on Linux is a process with a unique PID, and you inspect all processes with 'ps aux' or 'top'.
A process can be in one of several states: running (R), sleeping (S), stopped (T), or zombie (Z); zombie processes only need attention when their parent is broken.
To stop a process, first send SIGTERM (kill <PID>) for a graceful shutdown; only use SIGKILL (kill -9) if the process ignores the polite request.
Nice values range from -20 (highest priority) to +19 (lowest priority), and only root can assign a negative nice value to boost a process.
You can run a command in the background by appending an ampersand (&), bring it to the foreground with 'fg', and list background jobs with 'jobs'.
The 'nohup' command lets a process keep running even after you log out of the system, which is critical for long-running tasks over SSH.
A child process whose parent dies becomes an orphan and is adopted by init (PID 1), which automatically reaps it.
The load average in 'uptime' shows how many processes are waiting for CPU time; a load average above the number of CPU cores means the system is overloaded.
These come up on the exam all the time. Here's how to tell them apart.
SIGTERM (signal 15)
Politely asks the process to terminate
Process can ignore or handle it gracefully
Recommended first choice for stopping a process
SIGKILL (signal 9)
Forcefully kills the process immediately
Process cannot ignore or handle it
Use only when SIGTERM fails
ps aux
Takes a single snapshot of all processes
Output is static until you run the command again
Useful for scripting and viewing specific details
top
Shows a live, updating view of processes
Output refreshes every few seconds by default
Useful for real-time monitoring of CPU/memory usage
Parent Process
Creates other processes (children)
Child's PPID points back to the parent
If the parent dies, children become orphans
Child Process
Created by a parent process
Inherits environment and file descriptors from parent
If the child becomes a zombie, the parent must reap it
nice value 0 (default)
Default priority for most user processes
Process gets a fair share of CPU time
Root can lower this value to boost priority
nice value +19 (lowest priority)
Highest possible nice value (most 'nice')
Process gets CPU time only when no other process needs it
Used for background tasks that are not time-sensitive
Mistake
Killing a process with 'kill' always destroys it immediately.
Correct
By default, 'kill' sends SIGTERM (signal 15), which asks the process to terminate gracefully. Only 'kill -9' (SIGKILL) forces immediate termination. SIGTERM gives the process a chance to clean up and save data.
The word 'kill' sounds drastic, so beginners assume it always acts instantly. They do not realise that most processes can ignore the default SIGTERM, which is why you often need SIGKILL for stubborn processes.
Mistake
A zombie process is a serious problem that must be killed immediately.
Correct
A zombie process is a process that has finished executing but still has an entry in the process table because its parent has not read its exit status. Zombies use almost no system resources. The real issue is a parent process that is not cleaning up its children. To remove a zombie, you kill its parent process, not the zombie itself.
The name 'zombie' is scary, but in Linux it is a normal and temporary state. Beginners panic when they see zombie entries in 'ps' output, thinking the system is infected or critically broken.
Mistake
Running a command with 'nice -n -20' gives it the lowest possible priority.
Correct
The default nice value is 0. Negative values are higher priority. -20 is the highest priority (least 'nice' to other processes), and +19 is the lowest priority (most 'nice' to other processes). A command started with 'nice -n -20' gets the most CPU priority, not the least.
People confuse the range because 'nice' sounds like 'being kind', so they think a higher number is nicer. In fact, a high nice value means you are being 'nice' by giving others priority, so your process gets less CPU time.
Mistake
The 'top' command only shows processes you own.
Correct
By default, 'top' shows all processes on the system, sorted by CPU usage. You see processes from every user, including system daemons and other logged-in users. You do not need to be root to see the full list.
Windows Task Manager shows only processes for the current user by default, so new Linux users expect 'top' to behave similarly. They do not realise Linux is designed for multi-user transparency by default.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Run 'ps aux' to see every process from every user with detailed information. For a live updating view, use 'top' or 'htop'.
SIGTERM (signal 15) politely asks a process to terminate, giving it time to save data and release resources. SIGKILL (signal 9) forces immediate termination; the process cannot ignore or handle it, so data may be lost.
Use 'killall <processname>' to kill all processes with that name. For example, 'killall firefox' kills all Firefox processes. Alternatively, use 'pkill' with the same syntax.
State 'Z' means the process is a zombie. It has finished executing but its parent has not yet read its exit status. Zombies are harmless but signal a bug in the parent process. To fix it, kill the parent process, and the zombie will be reaped by init.
Use 'nice -n 10 <command>' to start a programme with a nice value of 10 (lower priority). The default nice value is 0, and you can go up to 19 (lowest priority). Only root can set negative values for higher priority.
Yes, using 'nohup <command> &'. The 'nohup' command protects the process from the SIGHUP signal that is sent when you log out, and the '&' runs it in the background.
You've finished Process Management and Monitoring. Continue through the LFCS study guide to build a complete picture of the exam.
Done with this chapter?