Linux Fundamentals — SRE Interview Q&A

The core Linux SRE/DevOps screen: processes, threads, signals, /proc/meminfo, load average, page faults, file descriptors, ss backlog, namespaces & cgroups, containers vs VMs.

The bread-and-butter Linux screen for an SRE/DevOps role: fast, correct answers about processes, memory, the network stack, and how you'd actually debug a box. Grouped the way interviewers ask them.

Quick-fire operations questions

              total   used   free   shared  buff/cache  available
Mem:          15884   3921    412       88       11550       11421
Swap:          2047      0    2047

$ nproc
8
$ lscpu | grep -E 'Socket|Core|Thread|CPU\(s\):'
CPU(s):              8
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           1

$ df -h /       Size  Used Avail Use% Mounted on
                 40G   34G  6.0G  86% /
$ df -i /      Inodes  IUsed  IFree IUse% Mounted on
               2.6M    148K   2.4M    6% /

State   Recv-Q  Send-Q  Local Address:Port   Process
LISTEN  0       511     0.0.0.0:80           users:(("nginx",pid=1201,fd=6))
LISTEN  0       128     0.0.0.0:22           users:(("sshd",pid=812,fd=3))

$ ls /proc/1201/fd | wc -l
42
$ lsof -p 1201 | awk '{print $5}' | sort | uniq -c | sort -rn | head -3
     28 IPv4      # sockets
      9 REG       # regular files
      3 CHR

$ uptime
 14:22:07 up 37 days,  4:12,  2 users,  load average: 1.20, 0.98, 0.71

$ ps -eo pid,ppid,stat,etime,comm | head -3
  PID  PPID STAT     ELAPSED COMMAND
    1     0 Ss     37-04:12  systemd
 1201     1 Ss     37-04:10  nginx

[Tue Aug 25 03:11:20 2026] Out of memory: Killed process 8842 (java) ...
[Tue Aug 25 03:11:20 2026] oom_reaper: reaped process 8842 (java) ...

Reading /proc/meminfo

free is just a friendly view of this file. The fields interviewers probe:

CPU & load average

Load average (the 1/5/15-minute numbers in uptime) is the average number of tasks runnable or waiting over that window. Compare it to core count: load 8 on 8 cores ≈ fully busy.

• Linux vs BSD difference: Linux load counts both CPU-runnable and D-state (uninterruptible, usually disk/IO) tasks — so a NFS/disk stall inflates load with near-zero CPU use. Classic BSD load counts only CPU run-queue demand, not I/O wait.
• Rising load + low CPU% → suspect I/O or lock contention, not compute. Confirm with iostat -xz 1 and D-state counts.

Processes, threads & syscalls

• Process vs thread: threads of one process share the same address space (heap, fds, mappings); each has its own stack and registers. On Linux both are tasks created by clone(); user threads are backed by libpthread.
• Syscall vs function call: a syscall traps into the kernel (mode switch), which performs a privileged operation on your behalf — that boundary crossing makes it far costlier than a plain function call. Trace them with strace -p <pid>.
• Process states: R running/runnable, S interruptible sleep, D uninterruptible sleep (in a syscall, usually I/O — can't be killed until it returns), Z zombie (exited, parent hasn't wait()ed — only a PID-table entry), T stopped.
• Zombies are reaped when the parent reads exit status; a leak means a buggy parent. Not memory hogs, but they consume PIDs.

Process states (the ps STAT letters)

The first letter is the state; the rest are modifiers. ps -eo pid,stat,comm / ps aux show them.

So Ssl = interruptible-sleep, session-leader, multithreaded (a typical daemon); R+ = running in the foreground. The two that page you: D (stuck I/O) and Z (parent not reaping) — both resist kill -9 for different reasons; see Linux Troubleshooting and Processes.

Signals

A signal is an asynchronous notification to a process — a basic IPC mechanism.

Page faults: minor vs major

• Minor fault: the page is already in RAM (e.g. shared library / page cache) but not yet mapped into this process's page tables — the kernel just wires it up. Cheap.
• Major fault: the page must be fetched from disk (demand-paged binary, swapped-out page) — a blocking I/O. A high major-fault rate (ps -o maj_flt, sar -B) signals memory pressure / thrashing.

Files, fds & the deleted flag

A file descriptor is a per-process handle to an open file/socket/pipe. When lsof -p <pid> shows a path marked (deleted), the directory entry was removed but a process still holds the fd open — so the inode and its disk blocks aren't freed yet. Classic cause: bad log rotation — the file is unlinked but the daemon keeps writing to the old fd, so df stays full while du can't find the space. Fix: signal the app to re-open (copytruncate or postrotate). See also Linux Basics.

Sockets: ss -lna and the backlog

For a TCP socket in LISTEN, the two queue columns aren't bytes:

When the accept queue is full (app too slow to accept()), new connections are dropped: the final ACK is ignored, so the client retransmits and eventually times out — and net.ipv4.tcp_abort_on_overflow / ListenOverflows counters climb (nstat, netstat -s).

Limiting process resources: namespaces & cgroups

The kernel primitives behind containers:

Namespaces decide what a process can see; cgroups decide how much it can use (CPU, memory, IO, PIDs) and account for it. cgroup v2 is the unified hierarchy. Inspect with lsns, nsenter, systemd-cgls, systemd-cgtop.

Containers vs virtual machines

The single most-asked ops question, so answer it in one line first: a VM virtualizes the hardware and runs its own kernel + OS; a container virtualizes the OS and shares the host's kernel. A VM is a fake machine (courtesy of a hypervisor); a container is just an isolated process (courtesy of namespaces + cgroups).

Container = namespaces (what it can see) + cgroups (how much it can use) + an image (userspace + deps), all running on the host kernel. VM = a hypervisor (KVM, ESXi, Hyper-V) giving a guest virtual CPU/RAM/disk/NIC, on which a full guest OS boots its own kernel.

• The key consequence — security: a container escape or a kernel vulnerability can affect the host and every other container (they share one kernel); a VM guest is contained by the hypervisor. That's why multi-tenant/untrusted workloads lean on VMs or "sandboxed" runtimes (gVisor, Kata Containers = a container packaged in a lightweight micro-VM).
• The key consequence — portability/speed: a container ships just userspace, so it's small, starts in ms, and packs densely — ideal for microservices, CI, and elastic scaling.
• Same-kernel constraint: a Linux container needs a Linux kernel — "Docker on a Mac/Windows" is really running a hidden Linux VM underneath.
• They compose: in the cloud you usually run containers inside VMs — the VM gives a hard tenant boundary, the container gives packaging and density. A container is not a "lightweight VM"; it's an isolated process.

Under the hood a container is exactly the namespaces & cgroups from the section above — no magic, just kernel features.

A couple more they like

• Work with a raw disk without a filesystem? Yes — you can read/write the block device directly (/dev/sdb) with dd, or let a database/LVM use raw block storage. A filesystem is just one consumer of the block layer.
• Why are /etc/passwd and /etc/shadow separate? /etc/passwd is world-readable (many tools resolve names/UIDs from it), so password hashes were moved to /etc/shadow, readable only by root — keeping hashes off a file every process can read.
• Trace a process's syscalls: strace (syscalls) / ltrace (library calls).