Services and processes

Read process state and relationships

Inspect PID, parent, user, state, start time, CPU time, memory, and command without trusting a process name alone.

8 minute lesson

~~~

A process list is a snapshot. Read identity and relationships before sending signals or attaching tools. Half of all “I killed it and it came back” and “I killed it and something else died” stories start with someone acting on a process name alone.

Ask ps for exactly what you need

Use ps with explicit columns instead of scanning the default output:

ps -o pid,ppid,user,stat,etime,nlwp,rss,cmd -C nginx
    PID    PPID USER     STAT     ELAPSED NLWP   RSS CMD
   1298       1 root     Ss      12-03:11:42    1  2140 nginx: master process /usr/sbin/nginx
   1299    1298 www-data S       12-03:11:42    1  4820 nginx: worker process
   1300    1298 www-data S       12-03:11:42    1  4716 nginx: worker process

The fields that matter: PPID tells you who owns this process (PPID 1 usually means systemd started it). STAT is the state. ELAPSED tells you if it restarted recently — a service that’s been “up” for 40 seconds after a 12-day incident has been crash-looping. NLWP is the thread count, and RSS is resident memory.

Read the state letter

The first character of STAT suggests your next question. R is running or runnable. S is sleeping, waiting for an event — normal for most of a server’s life. D is uninterruptible sleep, almost always waiting on I/O; a pile of D processes points at storage or NFS, not at the application. Z is a zombie: already dead, waiting for its parent to collect the exit status. T is stopped, often by a forgotten Ctrl-Z or a debugger.

See the family tree

Use pstree for parent-child structure:

pstree -p 1298
nginx(1298)─┬─nginx(1299)
            └─nginx(1300)

And confirm which systemd unit owns the process, because that’s who will react when you touch it:

systemctl status 1298 --no-pager | head -2
# ● nginx.service - A high performance web server

The trap: killing a zombie. A Z process is already dead; the PID in your ps output holds no memory and runs no code. Signaling it does nothing. The bug is in its parent, which never called wait(). Fix or restart the parent, and the zombie disappears.

Choose one service process on your machine and record its parent, user, state, elapsed time, threads, children, and systemd unit. That’s the identity card you want before the next lesson, where we start sending signals.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →