Linux processes and signals: ps, top, kill and nice

You’ll do everything as student on rocky01 over SSH, so nothing here can hurt the server. Make a folder for the lab first with mkdir -p ~/lab20 && cd ~/lab20. Your PIDs will be different from the ones below, so always use the numbers your own commands print.

1Your shell is a process too

Run this:

echo $$
ps -o pid,ppid,user,stat,cmd -p $$

You should see something like this:

1842
    PID    PPID USER     STAT CMD
   1842    1841 student  Ss   -bash

$$ is the PID of the shell you’re typing in. Its parent (1841) is the SSH session process that logged you in. “Ss” means sleeping and session leader, because bash spends nearly all its time waiting for you to type.

The dash in -bash marks a login shell.

✅ Checkpoint: You can name your shell’s PID and its parent PID.

2See every process on the box

Run this:

ps -eo pid,ppid,user,stat,comm | head -n 8
ps -eo stat= | cut -c1 | sort | uniq -c

You should see something like this:

    PID    PPID USER     STAT COMMAND
      1       0 root     Ss   systemd
      2       0 root     S    kthreadd
      3       2 root     S    pool_workqueue_
      4       2 root     I<   kworker/R-rcu_g
      5       2 root     I<   kworker/R-sync_
      6       2 root     I<   kworker/R-slub_
      7       2 root     I<   kworker/R-netns
     44 I
      1 R
     86 S

-e means every process and -o picks the columns, which is the style you’ll use most in scripts. The second command counts processes by state. On a quiet server you want almost all S and I, a few R, and no Z or D that stay around.

You’ll also see two older styles at work. ps aux (BSD style, no dash) adds %CPU, %MEM, VSZ and RSS, and ps -ef (UNIX style) shows PPID and the start time. Both are fine, but don’t mix the two styles in one command.

✅ Checkpoint: You know how many processes on rocky01 are sleeping and whether any are in Z or D.

3Draw the family tree

Run this:

pstree -ps $$
pstree -p 1 | head -n 15

You should see something like this (first command):

systemd(1)───sshd(1103)───sshd-session(1835)───sshd-session(1841)───bash(1842)───pstree(1990)

-p adds PIDs and -s shows the parents above your shell, not only its children. Here you can read how your login was built: sshd (the listener) started a session process for your connection, which started your bash, which started pstree. The second command shows the whole tree from systemd.

If you get “pstree: command not found”, it lives in the psmisc package: sudo dnf install psmisc on Rocky, sudo apt install psmisc on Ubuntu.

✅ Checkpoint: You can trace the chain from sshd down to your own bash.

4Start a test process, find it and look inside

Run this:

sleep 3600 &
pgrep -a sleep
ps -o pid,ppid,stat,ni,cmd -C sleep

You should see something like this:

[1] 2210
2210 sleep 3600
    PID    PPID STAT  NI CMD
   2210    1842 S      0 sleep 3600

pgrep -a searches by name and prints the PID with the full command line. ps -C sleep picks processes by command name. Both are safer than ps aux | grep sleep, which also finds the grep itself. Now read the same process straight from /proc (use your own PID):

grep -E '^(Name|State|Pid|PPid|Uid|VmRSS|Threads)' /proc/2210/status
ls -l /proc/2210/cwd /proc/2210/exe
tr '\0' ' ' < /proc/2210/cmdline; echo

You should see something like this:

Name:	sleep
State:	S (sleeping)
Pid:	2210
PPid:	1842
Uid:	1000	1000	1000	1000
VmRSS:	    1664 kB
Threads:	1
lrwxrwxrwx. 1 student student 0 Oct 27 10:31 /proc/2210/cwd -> /home/student
lrwxrwxrwx. 1 student student 0 Oct 27 10:31 /proc/2210/exe -> /usr/bin/sleep
sleep 3600

The status file gives you the state, parent, owner and real memory (VmRSS) in one place. cwd and exe are links to the folder it runs in and the program file. cmdline uses zero bytes between arguments, which is why you swap them for spaces with tr.

Try it yourself: build a find-a-process command in the Command Builder.

✅ Checkpoint: You found PID 2210 (or yours) three ways: pgrep, ps -C and /proc.

5Move jobs between foreground and background

Run this, then press Ctrl+Z:

sleep 900

You should see:

^Z
[2]+  Stopped                 sleep 900

Now send it to the background and list your jobs:

bg
jobs -l

You should see something like this:

[2]+ sleep 900 &
[1]-  2210 Running                 sleep 3600 &
[2]+  2224 Running                 sleep 900 &

Ctrl+Z paused the job (state T), bg let it carry on in the background, and jobs -l lists this shell’s jobs with their PIDs. The + marks the current job, the one fg brings back. Bring job 2 back with fg %2 and stop it with Ctrl+C.

✅ Checkpoint: jobs shows only %1 (sleep 3600) after you stopped job 2 with Ctrl+C.

6Change priority with nice and renice

Run this:

nice -n 10 sleep 3000 &
ps -o pid,ni,cmd -p $!
renice -n 15 -p 2231
renice -n 5 -p 2231

You should see something like this:

[2] 2231
    PID  NI CMD
   2231  10 sleep 3000
2231 (process ID) old priority 10, new priority 15
renice: failed to set priority for 2231 (process ID): Permission denied

The job started at nice 10, and you could raise it to 15 as a normal user. Going back down to 5 failed, because lowering a nice value needs root, even for your own process. With sudo it works:

sudo renice -n 5 -p 2231

2231 (process ID) old priority 15, new priority 5

On the util-linux renice that Rocky 10 and Ubuntu 26.04 ship, -n sets the value you give (absolute). If you want “5 more than now”, use renice --relative 5 -p PID. Old guides that say -n is always relative are describing other systems.

✅ Checkpoint: ps shows NI 5 for your sleep 3000 after the sudo renice.

7Watch it live with top

Run this:

top

Inside top, try these keys: P sorts by CPU, M by memory, 1 shows each CPU, u then student shows only your processes, k sends a signal to a PID, r renices one, and q quits. For a ticket or a script you want a snapshot, not a live screen, so use batch mode:

top -b -n 1 | head -n 10

You should see something like this:

top - 10:36:12 up  1:24,  1 user,  load average: 0.00, 0.01, 0.00
Tasks: 134 total,   1 running, 133 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  3.1 sy,  0.0 ni, 96.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   1742.2 total,   1009.8 free,    455.6 used,    432.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   1286.6 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2001 student   20   0  231460   5632   3456 R   6.2   0.3   0:00.01 top
      1 root      20   0   49288  40192  10624 S   0.0   2.3   0:02.11 systemd
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.02 kthreadd

The summary at the top gives you load, task states (including zombies) and memory. PR is the kernel priority, which top shows as 20 plus the nice value. Lesson 22 reads the memory lines in detail.

✅ Checkpoint: You sorted top by memory with M and quit with q.

8Send signals to a script that listens

Create the test script (paste this whole block):

cat > ~/lab20/worker.sh <<'EOF'
#!/bin/bash
# worker.sh: a pretend batch job that holds a lock file while it runs
LOCK=/tmp/worker.lock
if [ -e "$LOCK" ]; then
  echo "worker: already running (lock $LOCK exists)" >&2
  exit 1
fi
echo $$ > "$LOCK"
trap 'echo "worker: got TERM, cleaning up"; rm -f "$LOCK"; exit 0' TERM
trap 'echo "worker: got HUP, reloading settings"' HUP
while true; do sleep 1; done
EOF
chmod +x ~/lab20/worker.sh
bash -n ~/lab20/worker.sh && echo syntax ok

It writes its PID into a lock file, says something when it gets HUP, and removes the lock when it gets TERM. Real batch jobs and daemons behave like this. Start it, send HUP, then the default TERM:

cd ~/lab20
./worker.sh > worker.log 2>&1 &
pgrep -af worker.sh
kill -HUP 2260
sleep 2
kill 2260
sleep 2
cat worker.log; ls /tmp/worker.lock

You should see something like this:

[3] 2260
2260 /bin/bash ./worker.sh
worker: got HUP, reloading settings
worker: got TERM, cleaning up
ls: cannot access '/tmp/worker.lock': No such file or directory

HUP did not stop it, because the script chose to treat HUP as “reload”. Plain kill sent TERM, and the script cleaned up its lock before exiting. That’s the polite stop, and it’s what systemd sends first when you run systemctl stop.

Try it yourself: build the “TERM first, then KILL” stop command in the Command Builder.

✅ Checkpoint: worker.log has both lines and /tmp/worker.lock is gone.

9Keep a job running after the connection drops

Run this:

nohup ./worker.sh > worker.log 2>&1 &

Now close the terminal window itself (the X on PuTTY or Windows Terminal), which is what a dropped VPN looks like to the server. Log in again over SSH and check:

pgrep -af worker.sh
ps -o pid,ppid,stat,cmd -p $(pgrep -f worker.sh)

You should see something like this:

2290 /bin/bash ./worker.sh
    PID    PPID STAT CMD
   2290       1 S    /bin/bash ./worker.sh

When the connection dropped, bash got SIGHUP and passed it on to its jobs, but nohup had told this one to ignore it. Its parent is now 1, because the old bash is gone and systemd adopted it. nohup is fine for a one-off job, but anything that must keep running belongs in a systemd service, which you’ll write in Lesson 27. Clean up now:

pkill -TERM -f '^/bin/bash ./worker.sh$'
pkill -x sleep
pgrep -a sleep; pgrep -af worker.sh; echo "left: $?"

left: 1

✅ Checkpoint: pgrep finds nothing and exits with 1, so no lab processes are left running.