Processes¶

Practical 5.5 processes-annex.pdf · PDF

Open the calculator on your computer. Now open it again. How many calculators are installed? One. How many are running? Two. Right now your computer is running more than a hundred programs, and you started maybe three of them. Who started the rest? And can you stop them?

For a week you have protected files that sit still on the disk. Today the files wake up. When your laptop fan goes crazy, when a game freezes and ignores every click, when the computer feels slow for no reason, the answer is always in the same place: the list of running processes. Today you learn to read it and to act on it.

Recipe or dish? Program and process¶

Back to the kitchen of Unit 1: the CPU is the chef, RAM is the countertop, the disk is the pantry, and the operating system is the kitchen manager.

A program is a recipe in the book. A process is a dish being cooked: a program that is running.

The recipe sits in the pantry (the disk) and does nothing. When you start it, the recipe is copied to the countertop (RAM), together with its ingredients, the step it is on, and an order ticket with a number. The chef works on one dish per hand (each core of the CPU) and jumps between dishes many times per second, so they all seem to cook at once. The kitchen manager (the OS) hands out the tickets and decides who gets the chef next.

PID and parents: the family tree¶

The PID (Process ID) is the ticket number of a process: a number that identifies it in the whole system.

Every process is started by another one, its parent. The parent's PID is the PPID (Parent Process ID). Ask for process number 1:

$ ps -p 1 -o pid,ppid,user,comm
    PID    PPID USER     COMMAND
      1       0 root     systemd

PID 1 is systemd, the first process the kernel starts when the machine boots (remember the relay race in Boot). Its parent is 0, the kernel itself. Every other process descends from it, so the processes form a family tree.

flowchart TB
    K["<b>Kernel</b><br>shown as PPID 0"] --> S["<b>systemd</b><br>PID 1: the first ticket"]
    S --> G["<b>GNOME session</b><br>your desktop"]
    S --> D["<b>Background services</b><br>nobody started them by hand"]
    G --> T["<b>Terminal</b><br>the window you type in"]
    T --> B["<b>bash</b><br>your shell"]
    B --> P["<b>ps, sleep, ...</b><br>what you run"]

A process also carries the identity of the user who started it. The permissions you studied last week are checked against that user: a process started by marta can only touch what marta can touch.

Look at what is running¶

Four commands, from a photo to a live video. On deb-lab, install the two that are missing first (this needs the network once):

sudo apt install htop psmisc

ps: a photo¶

ps                     # only the processes of this terminal: bash and ps itself
ps aux | wc -l         # count every process in the system (plus one header line)
ps -u $USER | wc -l    # count only yours

A Debian with GNOME shows roughly 150 to 250 processes. Yours are a small part. ps aux is the full photo; its most useful columns are:

pstree: the family tree¶

pstree -p | head -15

The root of the tree is systemd(1). Follow it with your finger down to your own bash: it hangs from the terminal, which hangs from your desktop session.

top and htop: the live video¶

top refreshes the list every 3 seconds. Inside it, press P to sort by CPU, M to sort by memory, and q to quit. htop does the same with colours, one bar per CPU core and the function keys at the bottom: F6 to sort, F9 to kill, F10 to quit.

The first line of top ends with load average:. Keep it in mind: you will read it in Monitoring performance.

Process states¶

The STAT column (or S in top) is one letter:

Signals: you can only send a message¶

You cannot reach into a running process and change it. You can only send it a signal: a numbered message delivered by the kernel. The command for that is badly named: kill sends signals, and most of them are polite.

In the kitchen, SIGTERM is "last orders": the cook plates what is on the fire and cleans up. SIGKILL is switching off the gas: the dish is lost. A program that is saving a file when it gets kill -9 leaves half a file.

The proof is a small script, stubborn.sh, that ignores SIGINT and answers SIGTERM politely:

#!/bin/bash
trap 'echo "TERM received: saving and leaving"; exit 0' TERM
trap '' INT
echo "stubborn started with PID $$"
while true; do sleep 1; done

$ chmod u+x stubborn.sh
$ ./stubborn.sh
stubborn started with PID 4636
^C^C^C

Ctrl+C does nothing: the script ignores it. From a second terminal, kill 4636 makes the first one print TERM received: saving and leaving, and the prompt comes back. Run it again and use kill -9 4636: the first terminal prints only Killed. The goodbye message never appears, because the process had no chance to save.

Jobs: background and foreground¶

Normally a command takes over the terminal until it ends: it runs in the foreground. Add & at the end and it runs in the background: the terminal is free at once.

$ sleep 300 &
[1] 317
$ sleep 400 &
[2] 318
$ jobs -l
[1]-   317 Running                 sleep 300 &
[2]+   318 Running                 sleep 400 &

[1] is the job number: it belongs to this shell only. 317 is the PID: it is valid in the whole system. With them:

$ kill -STOP %1
[1]+   317 Stopped (signal)        sleep 300
$ kill -CONT %1
$ kill %1
[1]+   317 Terminated              sleep 300

Priorities: who gets the chef first¶

When there are more hungry processes than cores, the manager has to share the chef.

The nice value of a process goes from −20 (first in line) to 19 (after everyone else). The default is 0. A "nice" process lets the others go first.

$ nice -n 10 sleep 500 &
$ renice -n 15 -p 326
326 (process ID) old priority 10, new priority 15
$ renice -n 5 -p 326
renice: failed to set priority for 326 (process ID): Permission denied

nice starts a process with a given value; renice changes a running one. A normal user can only make their own processes nicer (a higher number). Going back down, or below 0, needs sudo. Why? Otherwise everybody would put their own processes first.

The runaway process: a real case¶

Marta's laptop at Tramuntana Apps has the fan at full speed. Something is eating the CPU. You can rehearse it: yes is a program that writes "y" for ever.

yes > /dev/null &      # the runaway; > /dev/null throws its output away
top                    # press P to sort by CPU

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   5062 marta     20   0    2584   1528   1420 R 100.0   0.0   0:01.19 yes

State R, about 100 %. Then the three moves of a calm administrator:

renice -n 19 -p 5062   # 1. calm it down: last in line
kill 5062              # 2. stop it politely
pgrep -a yes           # 3. check: prints nothing if it is gone
pkill yes              # or end every process called yes, by name

The same on Windows¶

Same ideas, other names. Ctrl+Shift+Esc opens Task Manager; its Details page shows the PID of each process.

Start-Process notepad
Get-Process notepad                     # one line, with its Id
Stop-Process -Name notepad              # -Name is needed: the first parameter is the Id
Get-Process | Sort-Object CPU -Descending | Select-Object -First 5

The last line is the PowerShell pipeline at work: the five processes with the most CPU time.

One real difference: Windows has no family of polite signals. Stop-Process and End task simply end the process. A program may still ask "save changes?" when you close its window, but not when you stop the process.

Now do all of it yourself, step by step, on the Practical 5.5 sheet (button at the top of the page).

Key takeaways¶

• A program is a recipe on the disk; a process is that program running in RAM, with a PID, an owner, a state and a parent (PPID). Everything descends from systemd, PID 1.
• ps aux is a photo, pstree the family tree, top/htop the live video. In top, 100 % is one core.
• kill sends signals: SIGTERM (15) asks politely and is the default; SIGKILL (9) cannot be caught, so the process cannot save.
• & runs a command in the background; jobs, fg, bg and Ctrl+Z move jobs around. Job numbers live in one shell, PIDs in the whole system.
• The nice value goes from −20 (first) to 19 (last); a normal user can only make processes nicer. It only matters when processes compete.
• On Windows: Task Manager, Get-Process, Stop-Process, and no polite signals.

Quick check¶

Next: the processes that nobody started by hand, and who brings them back when they die — Services and systemd.