Linux Internals
Above the everyday commands sits a smaller set of ideas that decide whether you truly understand what the machine is doing: what a process actually is, where its data really lives on disk, and what happens between power-on and a login prompt. Carry this model and a hung process, a "disk full" that df cannot explain, or a service that vanishes after reboot each resolves in seconds — recite commands without it and you flail.
This topic is that model in three parts. First the process: PID/PPID and file descriptors, fork+exec, the R/S/D/T/Z states, signals, and the zombie-versus-orphan distinction that catches so many. Then storage: inodes versus data blocks, why df and du disagree, LVM and RAID, mounts and iowait. Finally boot: firmware → GRUB → kernel+initramfs → systemd as PID 1, and the enable-versus-start confusion asked in nearly every interview. Each layer names its traps explicitly so you recognise them before an interviewer sets them.
Topic map
- Processes & signals — the process as a
PIDwith its own address space and file descriptors,fork+exec, the R/S/D/T/Z states, uncatchable signals, and why a zombie differs from an orphan. - Storage & filesystems — inodes versus data blocks, inode exhaustion, the
df-versus-dudivergence from a deleted-but-open file, LVM, RAID levels, and mounts. - Boot & systemd — the sequence from firmware through GRUB, kernel, and
initramfstosystemdas PID 1, plus theenable-versus-startdistinction and boot troubleshooting.
Common traps
| Mistake | Consequence |
|---|---|
Reaching for kill -9 on a zombie | Nothing happens — a zombie is already dead; you must make its parent reap it |
Expecting kill -9 to clear a D-state process | SIGKILL cannot be delivered until the blocking I/O returns; fix the storage, not the process |
| Deleting a large file to free space while a process holds it open | Space is not reclaimed until the fd closes; df and du disagree |
| Treating inodes as unlimited | Millions of tiny files exhaust inodes while df shows free space; check df -i |
Running systemctl start and assuming it survives reboot | The unit is still disabled; only enable links it into the boot target |
| Thinking a container needs its own kernel to boot | It shares the host kernel; there is no BIOS/GRUB/initramfs inside a container |
Interview relevance
These questions test the mental model, not trivia. "A zombie is a dead process the parent has not reaped, so kill -9 does nothing — fix the parent" instantly reads as someone who has debugged one. So does "high iowait means CPUs stall on disk, not that the CPU is busy", and "enable wires a service into a boot target, start only runs it now".
Typical checks:
- What
forkandexecdo, and the difference between a zombie and an orphan. - Why a
D-state process ignoresSIGKILL, and how to actually clear it. - Why
dfanddudisagree, and what inode exhaustion looks like. - The full boot chain and why
initramfsexists;enableversusstart.
Common wrong answer: "just kill -9 it." SIGKILL cannot touch a zombie (already dead) or a D-state process (blocked in the kernel until its I/O returns), and it skips a service's graceful shutdown. Knowing when force does nothing is the mark of the engineer who fixes the cause instead of hammering the symptom.