Learn › RHCSA (EX200) › Operate Running Systems

Process Triage

kill - a hands-on Linux lab on a real virtual machine.

Find a misbehaving process, then signal it correctly. List with ps -ef and ps aux, watch live with top, read the signals menu with kill -l, find PIDs by name with pgrep, pkill, and killall, and pick columns with ps -o. The core discipline: send SIGTERM with kill <PID first, and escalate to SIGKILL (kill -9) only as a last resort. Serves EX200 operating-systems: identify CPU or memory intensive processes and kill them.

A web server on the exam machine has gone rogue. It is pinning a CPU core at 100 percent and the box is crawling. You need it stopped, now. But you cannot just yank the power on one program the way you close a window. A running program is a process, and the only way to reach it is to send it a message the kernel delivers on your behalf.

Two things stand between you and a calm system: first you have to FIND the process, which means learning its PID, its numeric process ID. Then you have to SIGNAL it, and there is a right message and a wrong one. Send the polite message and a well-behaved program shuts down cleanly. Reach straight for the sledgehammer and you can corrupt its files on the way out. This lesson is that whole loop: find it, then signal it correctly. It is the EX200 operating-systems task: identify CPU or memory intensive processes and kill them.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs shown are from a real RHEL 10 machine (AlmaLinux 10.2). PID numbers and the exact list of running programs change every time a machine boots, so your numbers will differ. What never changes is the SHAPE of the output and the logic of which signal to send, and that is the lesson.

Every process has a unique PID, a number the kernel hands out the moment a program starts. PID 1 is always the very first process, the init system, which on RHEL 10 is systemd; every other process descends from it. You cannot signal a process you cannot name, and the name the kernel understands is the PID.

A signal is a short, fixed message the kernel delivers to a process on your command. The one you will send most is SIGTERM, the polite request to shut down: it lets the program save its work, close its files, and exit cleanly. The one you save for emergencies is SIGKILL, spelled -9, which the program cannot catch or ignore. The kernel simply erases it mid-breath, with no chance to clean up. The whole craft of process triage is: find the PID, send SIGTERM, and only escalate to SIGKILL if the polite request is ignored.

It is tempting to lead with kill -9 because it always works. Resist that. A program killed with SIGTERM gets a moment to flush its buffers to disk, finish writing a file, and release its locks. A program killed with SIGKILL gets none of that: half-written files, stale lock files, and a database that thinks it is still open. On the exam, reaching for -9 first can leave the system in the exact broken state the task is testing whether you can avoid. Polite first, force only when politeness is refused.

Before you can kill anything, you list what is running. ps prints a snapshot of processes, and the classic flags are -ef: -e for every process on the machine, -f for full detail. The output leads with a header row naming each column, then one line per process.

Run it and watch for the header and the very first process:

ps -ef

prompt: student@servera:~$ answer: ps -ef output: UID PID PPID C STIME TTY TIME CMD root 1 0 1 19:17 ? 00:00:01 /usr/lib/systemd/systemd --switched-root --system --deserialize=51 root 2 0 0 19:17 ? 00:00:00 [kthreadd] hint: Type ps, a space, then the two flags together: ps -ef

The header names the columns. PID is the process ID, the number you will aim signals at. PPID is the parent's PID, the process that started this one. CMD is the program and its arguments. Look at the first line: PID 1, PPID 0, running /usr/lib/systemd/systemd. That is the init system, the ancestor of everything else, which is why its parent is 0, nothing started it. Your PID numbers will differ from this capture; the columns and their meaning will not.

ps -ef is the System V flag style. There is a second, older BSD style, ps aux, that shows nearly the same picture with different column headers (USER %CPU %MEM ... STAT ... COMMAND) and no leading dash. Both are correct and both appear on the exam. Learn ps -ef as your default; recognize ps aux when you see it. The %CPU and %MEM columns in ps aux are what you scan to find a resource hog.

ps is a still photograph, taken once. When you want a live, refreshing view, sorted by the busiest process, the tool is top. It fills the screen and updates every couple of seconds, with the heaviest CPU user climbing to the front. Inside top you press P to sort by CPU, M to sort by memory, and q to quit. It is the fastest way to answer which process is eating this machine.

Because top takes over the whole screen and never returns on its own, it is not something the practice sandbox can grade, so there is no black box for it here. Just know the move: top to watch live and spot the hog, then note its PID and switch to kill to deal with it.

The kill command is how you send a signal. Despite the name, it does not only kill: it delivers whichever signal you name, and its whole menu is one flag away. kill -l lists every signal the kernel offers, each with its number and its name.

Print the list and read the first row:

kill -l

prompt: student@servera:~$ answer: kill -l output: 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP hint: The command is kill, then a space and a lowercase L flag: kill -l

Signal number 1 is SIGHUP, 2 is SIGINT (what Ctrl-C sends), 3 is SIGQUIT. Two numbers you must burn in are further down the same list: 9 is SIGKILL, the uncatchable force stop, and 15 is SIGTERM, the polite default. When you run kill with no signal named, it sends 15, SIGTERM. SIGHUP at number 1 has a second life: many daemons treat it as reload your config rather than hang up, which is why you sometimes see kill -HUP used to refresh a service without stopping it.

Reading a full ps -ef to find one PID by eye is slow. pgrep does it for you: give it a process name and it prints just the matching PIDs, one per line. It is the fast bridge from a name you know to the number you need.

Ask it for the PID of systemd, the init process you already know is PID 1:

pgrep systemd

prompt: student@servera:~$ answer: pgrep systemd output: 1 hint: Type pgrep, a space, then the process name: pgrep systemd

1. pgrep systemd searched the process table for a program named systemd and printed its PID, which for the init process is always 1. On a busy machine pgrep sshd or pgrep httpd may print several numbers, one per running copy. That list of PIDs is exactly what you feed to kill. The companion command pkill skips the middle step entirely: pkill sshd finds those same PIDs and signals them in one move, sending SIGTERM by default just like kill.

pkill and killall both signal by name instead of PID, but they match differently. pkill matches a pattern anywhere in the name, so pkill ssh would also catch sshd. killall matches the exact name, so killall sshd hits only processes named precisely sshd. The pattern match is convenient and dangerous in equal measure: pkill ssh on the exam can drop your own login session. When in doubt, find the PID with pgrep and signal that one number.

ps lets you choose exactly which columns you want with -o, naming each field. This is how you confirm a fact about a specific process instead of scrolling a wide table. Ask for three fields of the current shell: its pid, its ni (nice value, its scheduling priority), and its comm (the command name).

ps -o pid,ni,comm

prompt: student@servera:~$ answer: ps -o pid,ni,comm output: PID NI COMMAND 1891 0 bash hint: Use -o and a comma-separated field list, no spaces: ps -o pid,ni,comm

Three columns, exactly the ones you asked for. PID 1891 is this shell, NI 0 is its nice value (its default priority, a topic the next lesson takes further), and COMMAND is bash. The power of -o is precision: when a task asks you to report a specific process detail, you name the fields and get a clean, narrow answer instead of hunting across a full-width ps -ef. Your PID will differ from 1891; the shape of the three-column report will not.

Scaffolding off. No command is printed this time. You have every piece you need.

A background job of yours has a known process ID: 4242. It is a normal, well-behaved program, and you want it to shut down cleanly so it can save its work and release its files. Do NOT force it. Think about which command sends a signal, and which signal is the polite default that a program is allowed to catch and clean up after. The plainest form of the command is the right answer here.

prompt: student@servera:~$ answer: kill 4242 output: hint: The polite default signal, SIGTERM, is what kill sends when you name NO signal at all. Just the command and the PID.

kill 4242, with no signal flag, sends SIGTERM (signal 15), the polite request to shut down. That is the correct first move on any process you want stopped cleanly, because it gives the program its chance to flush files and release locks. It prints nothing on success; a silent return is the signal landing. Only if the process is still there a few seconds later do you escalate to kill -9 4242, the uncatchable SIGKILL. Leading with kill 4242 and forcing only when ignored is exactly the discipline the exam is checking.

You earned this cheat sheet. Every row is a form you just ran or built:

The one discipline to burn in for the exam: SIGTERM before SIGKILL. Find the PID with ps or pgrep, send the polite kill <PID> first, and reach for kill -9 only when the process refuses to go.

After you signal a process, VERIFY it is gone. Run pgrep <name> again, or ps -ef | grep <name>: an empty result means the signal worked. If the PID is still there after SIGTERM, wait a few seconds (it may be cleaning up), then escalate to kill -9. Signalling without checking is how a task looks done but is not.

The practice terminal has shown you the whole loop: ps -ef and ps aux to list processes, top for a live view, kill -l to read the signals menu, pgrep and pkill and killall to work by name, ps -o to pick your columns, and above all kill <PID> for the polite SIGTERM before you ever reach for kill -9. Every one of those you typed yourself.

The operating-systems module mission is where you run these against a real RHEL 10 machine. A full VM boots for you, with its own live processes, its own PIDs, and a resource hog planted for you to find. The mission hands you objectives that use exactly what you practiced here: identify the process eating CPU or memory, and stop it with the right signal. One difference from this lesson: the mission shows no commands. You read the objective, recall the ps, the pgrep, and the kill, and type them. That recall is what makes it stick on exam day.

Finish the other operating-systems lessons, then go quiet a real machine that will not settle down.

Practice Process Triage in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.