Page 1 of 3
Every time you deploy a service, SSH into a box to check on it, or watch a container get killed and restarted, you're watching the operating system do its actual job: sharing one machine's CPU, memory, and I/O between many competing programs, safely and (mostly) fairly. Application code doesn't talk to hardware directly. It talks to the kernel, the core of the operating system that owns the hardware and hands out access to it in small, controlled slices. Everything else, including the shell you type commands into, is just another program running on top of that kernel.
For most day-to-day scripting or app development, you can get away with barely thinking about any of this. Running production services is different. When a service gets killed unexpectedly, when a deploy hangs on shutdown, when a container mysteriously restarts under load, or when a server that "isn't doing much" is somehow slow, the answer usually lives one layer below the application, in how the OS is scheduling, allocating, or reclaiming resources. This tutorial builds that layer up from first principles, with an eye toward the parts that actually show up in an incident channel.
A process is a running instance of a program: its own memory, its own open files, its own execution state, tracked by the kernel as a single unit. Every process has a PID (process ID), a number the kernel assigns when it's created, and almost every process also has a PPID (parent PID), the process that created it.
ps -ef | head -5
# UID PID PPID C STIME TTY TIME CMD
# root 1 0 0 09:02 ? 00:00:03 /sbin/init
# root 412 1 0 09:02 ? 00:00:01 /usr/sbin/sshd
# alice 980 412 0 09:14 pts/0 00:00:00 -bash
# alice 1022 980 0 09:15 pts/0 00:00:00 ps -ef
Read that as a family tree. PID 1 is the very first process the kernel starts at boot (its own PPID is 0, meaning "the kernel itself"), and everything else descends from it, directly or indirectly. When you type a command in your shell, the shell doesn't turn into that command, it creates a new process for it using fork, which makes a near-identical copy of the running process, and then that copy typically calls exec, which replaces its own memory and code with the new program you asked for. This fork-then-exec pattern is how every process on a Linux system comes into existence.
Why this matters operationally: when a parent process dies, its children don't necessarily die with it, and if a parent exits without ever checking on a child that already finished, that child can linger as a zombie (more on that below). Process trees are also how you find "what actually started this thing" during an incident, since pstree or ps -ef will show you the whole ancestry, not just the misbehaving process in isolation.
A thread is a separate path of execution within a process, and a process can have many of them. The key difference from a process is what's shared: threads within the same process share the same memory space, the same open file descriptors, and the same everything except their own execution stack and register state. Two processes, by contrast, are isolated from each other by default; one can't casually reach into the other's memory.
That shared-memory property is exactly why threads are useful (a multi-threaded web server can hand work off to multiple threads without copying data between them) and exactly why threaded programming is dangerous: two threads writing to the same piece of shared memory at the same time, with no coordination, is a race condition, one of the hardest classes of bug to reproduce reliably. A crashed thread can also take its whole process down with it, since threads share an address space, whereas a crashed process is contained to itself. When you see a service running as "one process, many threads" versus "many separate processes," that's a real architectural choice with real tradeoffs, not just an implementation detail.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.