Hệ điều hànhOperating Systems

Part of the DevOps Roadmap knowledge base.

Overview

The operating system is the layer every DevOps engineer ultimately stands on. Containers are Linux processes with namespaces and cgroups; Kubernetes nodes are Linux machines; CI runners, databases, and load balancers all live or die by OS-level behavior — memory pressure, file descriptor limits, scheduler decisions, disk I/O. When an application “randomly” dies, the answer is usually in the OS: the OOM killer, a full disk, an exhausted inode table, or a misconfigured systemd unit.

Linux dominates servers and the cloud, so it deserves most of your attention. But real environments are heterogeneous: you will meet Windows Server in enterprise shops (Active Directory, IIS, .NET workloads), and BSD systems in networking appliances and storage (pfSense, FreeNAS/TrueNAS). Understanding OS concepts — processes, memory, file systems, I/O, sockets — transfers across all of them and is far more durable than memorizing any single distro’s quirks.

For DevOps specifically, OS knowledge shows up daily: sizing instances, tuning kernel parameters, writing systemd units, reading top/vmstat output during incidents, understanding why a container was OOM-killed, and debugging “connection refused” versus “connection timed out.” The recurring theme is that abstractions leak: a container is not a lightweight VM, it is a fenced-off Linux process, and when it misbehaves the fence (namespaces, cgroups, the shared kernel) is where you look. Every layer above — Docker, Kubernetes, the cloud console — is ultimately issuing system calls to a kernel, and when things break at scale, the kernel’s view is the truth.

Fundamentals

The Linux distribution landscape

Key practical differences: package manager and release cadence (Ubuntu LTS every 2 years with 5 years support, RHEL ~10-year lifecycle), security module (SELinux on the RHEL family vs AppArmor on Ubuntu/SUSE), default file locations, and default init/network stacks. Alpine uses musl libc instead of glibc and BusyBox instead of GNU coreutils — a common source of subtle container bugs (DNS resolution differences, missing bash, different date/getopt behavior).

A practical framing of “immutable” and container-optimized distros (Flatcar, Bottlerocket, Talos): the OS is read-only and updated as an atomic image rather than package-by-package. This eliminates configuration drift and is increasingly how Kubernetes node images are built.

Unix (BSD) and Windows

• FreeBSD: renowned networking stack and ZFS support; basis of pfSense/OPNsense firewalls and (historically) Netflix’s CDN appliances. Uses pkg and the ports tree; init is rc.d, not systemd. Jails predate Linux containers conceptually.
• OpenBSD: security-first (“secure by default”); origin of OpenSSH, pf, and LibreSSL, which you use every day even on Linux.
• macOS (Darwin): a certified UNIX built on the XNU kernel; the developer workstation of much of the industry. Behaves like BSD userland, which is why some GNU flags (sed -i, date) differ from Linux — a frequent scripting portability trap.
• Windows Server: matters where Active Directory, IIS, MSSQL, or .NET Framework live. Learn PowerShell, Windows services (services.msc, sc.exe), Event Viewer, Task Scheduler, and WSL2 for a real Linux kernel on Windows. Windows containers exist but are niche compared to Linux containers.

Kernel vs. user space and the system call boundary

The kernel manages hardware, memory, scheduling, and enforces isolation; applications run in user space and request privileged services via system calls (open, read, write, fork, execve, mmap, socket). This boundary is the single most important mental model in OS work: a program cannot touch hardware or another process’s memory directly — it asks the kernel, which decides. strace shows you this boundary live and is often the fastest way to answer “what is this process actually doing / waiting on?”

strace -f -e trace=openat,connect -p <pid>   # what files/sockets is it touching?
strace -c ./program                          # syscall count + time summary (find the hot syscall)

Processes, threads, and scheduling

• Process: a running program with its own virtual address space, PID, environment, open file descriptors, credentials, and exit code. Created by fork() (clone the parent) then exec() (replace the image); parents wait() on children. A child that has exited but not been reaped becomes a zombie (holds only a PID + exit status); a child whose parent died is re-parented to PID 1 (orphan).
• Threads: units of execution that share their process’s address space and file descriptors, making them cheap to create and to switch between, but prone to data races; synchronization uses mutexes, semaphores, and condition variables. On Linux, threads are just processes that share memory (both are “tasks” to the scheduler).
• Scheduling: the CFS scheduler time-slices runnable tasks across CPUs. nice/renice (–20 to +19) adjusts priority; taskset pins to CPUs; cgroups cap CPU shares. The run queue length relative to CPU count is your headline CPU-saturation signal.
• POSIX: the portability standard defining the shell, core utilities, and the C API (signals, file operations, pthreads). It is why a shell script or C program can run on Linux, macOS, and FreeBSD alike, and why “POSIX-compliant” is a meaningful promise.

Key Concepts

Memory management and virtual memory

Each process sees a private virtual address space; the kernel maps pages (typically 4 KB, optionally 2 MB/1 GB “huge pages”) to physical RAM on demand via the MMU, and a page not yet touched costs nothing until first access (demand paging). Consequences you will meet in production:

• Page cache: “free” memory is used to cache disk data — free -h showing low “free” but high “available” is healthy, not a leak. The kernel will evict cache instantly under pressure.
• RSS vs. VSZ: Resident Set Size is physical RAM actually used; Virtual Size includes everything mapped (shared libraries, reserved-but-unused, memory-mapped files) and is almost always alarmingly large and mostly meaningless. Alert on RSS/working set, not VSZ.
• Swap: overflow of anonymous memory to disk. Some swap is fine; heavy swapping (see si/so in vmstat) destroys latency because disk is orders of magnitude slower than RAM. Kubernetes historically disabled swap entirely for predictability.
• OOM killer: under memory exhaustion the kernel kills the process with the highest badness score (oom_score, tunable via oom_score_adj). Check with dmesg | grep -i oom. In Kubernetes, exceeding a container memory limit triggers a cgroup OOM kill (exit code 137 = 128 + SIGKILL/9).
• Overcommit: Linux grants more virtual memory than physical RAM exists (vm.overcommit_memory), which is why malloc succeeds but actually writing the pages later can get you OOM-killed — allocation and commitment are decoupled.

free -h                        # memory overview (watch "available", not "free")
vmstat 1                       # si/so columns = swap-in/swap-out activity
cat /proc/<pid>/status | grep -E 'VmRSS|VmSwap|VmHWM'
cat /proc/<pid>/oom_score      # how attractive this pid is to the OOM killer
dmesg -T | grep -i 'killed process'   # OOM killer victims with timestamps

Process management and signals

ps aux --sort=-%mem | head     # top memory consumers
ps -ef --forest                # process tree (parent/child relationships)
pgrep -af nginx                # find PIDs by name, show the full command
kill -TERM <pid>               # polite: ask to shut down (default signal)
kill -KILL <pid>               # last resort: cannot be caught or ignored
kill -HUP <pid>                # convention: reload configuration
nice -n 10 ./batch-job         # start with lower CPU priority
renice -n 5 -p <pid>           # change priority of a running process

Know the common signals and, critically, which can be caught: SIGTERM (15, graceful stop — what Kubernetes and systemctl stop send first, catchable), SIGKILL (9, immediate, uncatchable and unblockable), SIGHUP (1, terminal hangup, conventionally “reload config”), SIGINT (2, Ctrl-C), SIGSTOP/SIGCONT (pause/resume, also uncatchable), SIGCHLD (a child changed state). Graceful shutdown — finishing in-flight requests, flushing buffers, closing connections — depends entirely on your application installing a SIGTERM handler. Kubernetes sends SIGTERM, waits terminationGracePeriodSeconds (default 30), then SIGKILL.

File systems and I/O

• Common Linux file systems: ext4 (default, reliable, good all-rounder), XFS (RHEL default, excellent for large files and parallel I/O), Btrfs/ZFS (snapshots, checksums, copy-on-write, built-in RAID), overlayfs (the layered union FS that container images are built from), tmpfs (RAM-backed, e.g. /dev/shm and many /run mounts).
• Everything is a file: regular files, directories, devices (/dev), kernel/process state (/proc, /sys), sockets, and pipes all present through the same file descriptor API (open/read/write/close). This uniformity is a defining Unix design choice.
• Inodes store file metadata (permissions, owner, timestamps, block pointers) but not the name — names live in directory entries. You can run out of inodes (many tiny files) while df -h still shows free space; check df -i.
• Hard links vs. symlinks: a hard link is another directory entry pointing at the same inode (same file, multiple names, one on-disk copy); a symlink is a small file containing a path (breaks if the target moves).
• Permissions: the rwx triad for user/group/other, plus special bits — setuid/setgid (run as file owner/group), and the sticky bit on /tmp (only the owner can delete their files). ACLs (getfacl/setfacl) extend this when the classic model is too coarse.
• File descriptors are per-process integer handles to open files/sockets; exhaustion causes “too many open files” — check limits with ulimit -n and usage with ls /proc/<pid>/fd | wc -l.
• I/O paths: buffered I/O goes through the page cache and returns fast; fsync/fdatasync forces data to durable storage, which is why databases care so deeply about disk flush behavior and why a lying disk cache corrupts databases on power loss.

df -h && df -i                 # space AND inode usage — check both
lsof +D /var/log | head        # who holds files open under a path
lsof -p <pid>                  # everything a process has open (files, sockets, pipes)
iostat -xz 1                   # per-device I/O latency (await) and utilization
mount | column -t | head       # what is mounted where, with which options
du -sh /var/* | sort -h        # find what is eating disk space

The /proc and /sys pseudo-filesystems

/proc and /sys are the kernel exposed as files — no special tools required, just cat. This is where much of the deep introspection happens: /proc/<pid>/ holds a process’s status, cmdline, environ, fd/, limits, and cgroup; /proc/meminfo, /proc/loadavg, /proc/mounts, and /proc/net/ expose system state. /sys exposes device and kernel-object trees. Kernel tunables live under /proc/sys and are set with sysctl (persisted in /etc/sysctl.d/):

sysctl vm.swappiness                       # read a tunable
sysctl -w net.core.somaxconn=1024          # set at runtime (lost on reboot)
cat /proc/1/cgroup                          # which cgroups PID 1 belongs to

Sockets and networking basics

A socket is a communication endpoint identified by protocol + IP + port. TCP is connection-oriented (three-way handshake, retransmission, ordering, flow/congestion control); UDP is connectionless “fire-and-forget” (no delivery guarantee, lower overhead — used by DNS, QUIC, VXLAN). Practical implications you will diagnose constantly:

• “Connection refused” = the host is reachable and actively rejected you — nothing is listening on that port (or a RST came back). “Connection timed out” = packets are being silently dropped (firewall/security group, routing black hole, or a dead host). These two errors point at completely different layers.
• TCP connection states matter: LISTEN, ESTABLISHED, TIME_WAIT (the side that closed first holds the socket ~60s to absorb stray packets). Piles of TIME_WAIT plus ephemeral port exhaustion (the /proc/sys/net/ipv4/ip_local_port_range pool) is a classic failure on busy outbound proxies and load generators.
• Unix domain sockets (e.g. /var/run/docker.sock) are local-only IPC using file-system paths and permissions instead of ports — faster than loopback TCP and secured by filesystem ACLs.

ss -tlnp                       # listening TCP sockets + owning process
ss -tan state established      # established connections
ss -s                          # socket state summary counts

Startup and service management: init and systemd

PID 1 is the first user-space process the kernel starts, and the ancestor of everything (it also reaps orphaned zombies). Historically SysV init ran ordered shell scripts in /etc/init.d with numeric runlevels. Modern Linux uses systemd, which manages units — services, timers, mounts, sockets, targets — with declarative dependencies, parallel startup, cgroup-based process supervision, socket activation, and centralized logging via journald.

# /etc/systemd/system/myapp.service
[Unit]
Description=My App
After=network-online.target
Wants=network-online.target

[Service]
User=myapp
ExecStart=/usr/local/bin/myapp --config /etc/myapp.yaml
Restart=on-failure
RestartSec=5
# resource limits (same cgroup mechanism containers use)
MemoryMax=512M
CPUQuota=50%
LimitNOFILE=65536
# sandboxing hardening
NoNewPrivileges=true
ProtectSystem=strict
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload           # re-read unit files after editing
sudo systemctl enable --now myapp      # start now AND on boot
systemctl status myapp                 # state, recent logs, main PID, cgroup
systemctl list-units --failed          # what is broken right now
journalctl -u myapp -f --since "10 min ago"   # follow this unit's logs
journalctl -p err -b                   # error-priority messages, this boot
systemd-analyze blame                  # slowest units at boot
systemctl mask <unit>                  # forcibly prevent a unit from starting

Related concepts: targets (multi-user.target, graphical.target) replace runlevels; systemd timers are a more observable, dependency-aware alternative to cron (they log to the journal and can catch missed runs with Persistent=true); socket activation starts a service on first connection; and Restart= policies replace hand-rolled supervisor scripts. The MemoryMax/CPUQuota limits use the same cgroups v2 mechanism that containers use — systemd and Kubernetes are, at this layer, doing the same thing.

Containers are OS features, not magic

It is worth stating explicitly because it demystifies so much: a Linux container is a normal process that the kernel has isolated using namespaces (separate views of PIDs, mounts, network interfaces, users, hostnames, IPC) and constrained using cgroups (limits and accounting for CPU, memory, I/O, PIDs). There is no “container” object in the kernel — Docker and containerd just orchestrate clone() with namespace flags, set up an overlayfs root, apply cgroup limits, and (usually) a seccomp/AppArmor profile. This is why every OS concept above applies directly inside containers, and why nsenter, /proc/<pid>/ns, and reading a container’s cgroup files are core debugging skills.

Best Practices

1. Learn one distro from each major family (Ubuntu + a RHEL clone like Rocky/Alma). Package management, security tooling (SELinux vs AppArmor), and defaults differ; the underlying concepts transfer completely.
2. Diagnose from the OS up, not the app down. During incidents check the four fundamentals — CPU, memory, disk, network (top, free -h, df -h/df -i, ss) — before diving into application logs. The OS often already knows the answer.
3. Treat “available” memory, not “free”, as your headroom. Page cache is reclaimable on demand; alarms on “free” memory create false pages and hide real leaks.
4. Always send SIGTERM before SIGKILL, and build applications that shut down gracefully on SIGTERM — Kubernetes, systemd, and docker stop all rely on this contract. A missing SIGTERM handler means dropped requests and corrupt state on every deploy.
5. Run services under systemd (or the platform’s supervisor), never nohup ... &. You get automatic restarts, log capture, dependency ordering, resource limits, and sandboxing for free — and a process that survives your SSH session ending.
6. Set explicit resource limits (ulimit/LimitNOFILE, MemoryMax, container requests/limits) so one runaway process cannot starve or crash the whole host. Unlimited is a decision, usually the wrong one.
7. Monitor inodes and file descriptors, not just disk bytes. df -i running out and fd exhaustion take systems down while df -h and dashboards still look green.
8. Keep systems patched on a schedule — enable unattended security updates where safe, track your kernel-reboot strategy (or use livepatch/kexec), and know your CVE exposure. Unpatched kernels are the most common privilege-escalation vector.
9. Don’t disable SELinux/AppArmor reflexively. Learn audit2allow/aa-logprof to fix the actual denial. A disabled LSM is a permanent security regression traded for a one-time inconvenience.
10. Use journalctl and dmesg as first-class incident tools. OOM kills, disk errors, segfaults, and kernel warnings land there, not in application logs. dmesg -T for human timestamps.
11. Understand your file system before you choose it. Snapshots and checksums (ZFS/Btrfs), large-file and parallel-I/O behavior (XFS), and fsync durability semantics directly determine database and backup safety.
12. Tune kernel parameters deliberately and persist them. File descriptor limits, vm.swappiness, net.core.somaxconn, net.ipv4.tcp_tw_reuse, ephemeral port range — set them in /etc/sysctl.d/ (not just at runtime) with a comment explaining why.
13. Right-size before you scale out. Read vmstat/iostat/sar to learn whether a workload is CPU-, memory-, or I/O-bound; the bottleneck dictates the instance type and whether more replicas even help.
14. Prefer immutable, image-based nodes (Bottlerocket/Flatcar/Talos, or golden AMIs) over long-lived pets you patch in place. Replaceable infrastructure eliminates configuration drift.
15. Understand the namespace/cgroup basis of containers. When a pod is OOM-killed, throttled, or “cannot see” the network, the answer is in the OS primitives, not in Kubernetes abstractions.
16. Practice on disposable VMs. Break things deliberately — fill a disk, trigger the OOM killer, exhaust file descriptors, mask a unit, saturate CPU — so the first time you see the failure signature is not in production.

References

• DevOps Roadmap — roadmap.sh/devops
• The Linux Kernel documentation
• The Linux man-pages project
• Ubuntu Server documentation
• Red Hat Enterprise Linux documentation
• Arch Linux Wiki — distro-neutral, high quality
• systemd documentation and systemd.service man page
• FreeBSD Handbook
• OpenBSD FAQ
• Microsoft Windows Server documentation
• The Linux Documentation Project
• Brendan Gregg — Linux Performance
• Julia Evans — zines & blog on Linux internals
• Book: Operating Systems: Three Easy Pieces — Arpaci-Dusseau (free online)
• Book: How Linux Works — Brian Ward (No Starch Press)
• Book: The Linux Programming Interface — Michael Kerrisk (No Starch Press)
• Book: Systems Performance — Brendan Gregg (author site)