Processes, signals, init

Что отвечать

The container exits immediately. PID 1 is special in Linux. When it dies, the kernel sends SIGKILL to every other process in that PID namespace, and the namespace is torn down. On the host, a dead PID 1 (usually systemd) is a kernel panic.

Что хотят услышать

A senior should: - separate PID 1 on the host from PID 1 in a container's namespace - name the duties of PID 1: reaping zombies and handling SIGTERM - mention `tini` and `dumb-init` and the `docker run --init` flag - explain why `bash` as PID 1 is a bad idea (by default it does not react to SIGTERM and does not reap zombies)

Подводные камни

• ✗ Saying 'the system will panic' without the namespace caveat. That only happens for the host's PID 1.
• ✗ Forgetting that PID 1 must call wait() for orphaned children, otherwise they become zombies.
• ✗ Believing node, python, or java as the ENTRYPOINT works correctly as PID 1. Most runtimes have no built-in reaper.

Follow-up

• ? What is tini for, and why did Docker make `--init` a separate flag instead of the default?
• ? What happens if PID 1 ignores SIGTERM but `docker stop` sends it?
• ? How does Kubernetes tell a clean pod exit apart from a PID 1 crash?

Что отвечать

An orphan is a process whose parent died earlier; the kernel reparents it onto PID 1. A zombie is a process that has ALREADY died, but whose parent never called `wait()` to collect the exit code; the entry stays in the process table with status `Z`. You cannot kill a zombie with a signal, since it is already dead.

Что хотят услышать

A candidate should understand that: - a zombie consumes no resources beyond a slot in the process table, but a large number of them hits pid_max (32768 or 4M by default) - you cannot fix a zombie with a signal, only kill it or wait for the parent's wait() - the right move is to kill the parent: PID 1 (or an init wrapper like tini) reparents the child and calls wait() itself - in a container, a missing zombie reaper in PID 1 is a time bomb

Подводные камни

• ✗ Swapping them: a zombie is dead and waiting for wait(), an orphan is alive but has no parent.
• ✗ Saying `kill -9` kills a zombie. No, a zombie is already dead and kill does nothing.
• ✗ Not mentioning SIGCHLD, the signal the kernel sends the parent when a child dies.

Follow-up

• ? How do you find every zombie in the system with one command?
• ? What is `SIGCHLD`, and how can a process ignore it to avoid calling wait()?
• ? What does `prctl(PR_SET_CHILD_SUBREAPER)` do, and why do tini and systemd-user need it?

Что отвечать

SIGTERM (15) is a polite request to exit: the process gets a chance to flush buffers, close files, and wait for its children. SIGKILL (9) lets the kernel kill the process at once, with no chance to clean up. The standard workflow: TERM, wait N seconds, then KILL only if it has not exited.

Что хотят услышать

A senior should say: - SIGKILL and SIGSTOP are the only signals you cannot catch or ignore (the kernel handles them directly) - SIGKILL runs no finalizers, no fsync, and releases no application-level locks, so you can end up with corrupt files - a process in D-state (uninterruptible sleep, usually waiting on disk or NFS) does not react even to SIGKILL, since it is stuck inside a syscall - in Kubernetes, `terminationGracePeriodSeconds` is exactly that interval between SIGTERM and SIGKILL

Подводные камни

• ✗ Saying 'kill -9 always works'. No, you cannot kill a D-state process.
• ✗ Not mentioning that SIGKILL gives the process no chance to release locks or buffers.
• ✗ Thinking SIGTERM equals SIGKILL by default. `kill <pid>` with no signal sends SIGTERM.

Follow-up

• ? What is D-state, and how do you get a process out of it?
• ? What happens to a process's TCP connections on SIGKILL?
• ? Which signals does a process ignore by default (SIGCHLD, for example)?

Что отвечать

`fork()` makes a copy of the current process (parent and child are identical, differing only in PID and in fork's return value). `exec()` replaces the current process image with another binary while keeping the PID. The split lets the child set up its environment (variables, fds, signal handlers) BEFORE it launches the new binary, which is what the shell does for pipes and redirects.

Что хотят услышать

A candidate should: - explain copy-on-write: fork does not physically copy memory pages, only the page tables, and the copy happens on the first write - name `vfork()` and `posix_spawn()` as optimizations - give an example: the shell calls `fork`, the child closes stdin, opens a file as fd 0, then calls `exec`; that is how `cmd < file` works - mention `clone()` as the more general syscall (fork is a wrapper over clone with default flags)

Подводные камни

• ✗ Saying fork is slow. On modern Linux with COW it is cheap.
• ✗ Forgetting that after fork both parent and child run the same code up to the `if (pid == 0)` check.
• ✗ Not mentioning that the child inherits the fds, which is what makes shell pipes work.

Follow-up

• ? What is copy-on-write, and how does it show up in /proc/<pid>/smaps?
• ? How does `clone()` differ from `fork()`, and what flags does it take?
• ? Why is `fork()` dangerous in multi-threaded programs (a mutex can stay locked in the child)?

Что отвечать

Namespaces isolate **what a process sees** (its own PID tree, its own network, its own mount table, its own users). Cgroups limit **how much a process can consume** (CPU, RAM, IO, PIDs). A container is a process with its own namespaces plus cgroup limits. These are two independent kernel subsystems that Docker and runc glue together.

Что хотят услышать

A senior should name: - the 8 namespace types: mnt, net, pid, user, uts, ipc, cgroup, time - that cgroups v2 (since 2016) is a single hierarchy, unlike v1 where each resource lived in its own tree - `unshare`, `nsenter`, and `clone()` with the CLONE_NEW* flags as the low-level tools for namespaces - that a VM and a container are different technologies: a VM emulates hardware, a container shares the kernel with the host

Подводные камни

• ✗ Calling a container a 'lightweight VM'. That is wrong from an engineering standpoint.
• ✗ Confusing namespaces and cgroups: namespaces are not limits.
• ✗ Forgetting the user namespace, the hardest one, needed for rootless containers.

Follow-up

• ? What happens if a process inside a container tries to `mount`?
• ? How do `memory.high` and `memory.max` work in cgroups v2?
• ? How does a rootless container differ from a regular one, and which namespaces come into play?

Что отвечать

When the kernel runs short of memory and cannot free pages by reclaim, the OOM killer kicks in. It computes an `oom_score` for each process (roughly: the process's percent of memory times some penalties) and kills the one with the highest score. You can influence this through `/proc/<pid>/oom_score_adj` (-1000 to 1000, where -1000 means immune).

Что хотят услышать

A candidate should say: - the OOM killer works off the per-cgroup limit, not total RAM (when the process is in a cgroup with memory.max) - you find it in the logs with `dmesg | grep -i oom` or `journalctl -k --grep=oom` - `oom_score_adj=-1000` makes a process unpickable (systemd often sets this for critical services) - swap does not save you from OOM, it only delays it; thrashing is worse than OOM - `earlyoom` and `systemd-oomd` are userspace OOM daemons that trigger before the kernel OOM

Подводные камни

• ✗ Saying the OOM killer picks the 'oldest' or 'largest' process. It actually picks by oom_score, and the formula is more involved.
• ✗ Confusing `oom_score` and `oom_score_adj`: the kernel computes the first, the admin sets the second to influence the choice.
• ✗ Not mentioning that an OOM in a cgroup kills a process INSIDE that cgroup, not globally. Those are different cases.

Follow-up

• ? How do you find who the OOM killer killed last, and which logs do you read?
• ? How does `systemd-oomd` differ from the kernel OOM killer?
• ? Why does swap not save you from OOM, and when does swap still make sense?

Что отвечать

`ps` is a snapshot of the processes at the moment you call it (it reads `/proc/*/stat` once). `top` and `htop` are a live window that rereads the same data every N seconds and computes the delta (CPU% over the interval). For 'what is running right now' use ps; for 'what is loading the system this second' use top or htop.

Что хотят услышать

A senior should know: - both read `/proc/<pid>/stat`, `/proc/<pid>/status`, and `/proc/<pid>/cmdline` - CPU% in ps is the total since the process started (almost useless) - CPU% in top is over the last sampling interval, the real load - `ps aux` (BSD style) versus `ps -ef` (Unix style) are two formats that work the same way with different output - htop adds a TUI, signals on F9, and a tree view on F5, but underneath it is the same `/proc`

Подводные камни

• ✗ Using `ps aux | grep myproc` to check load. The CPU% is an average over the whole lifetime.
• ✗ Not knowing that top sorts by CPU% by default while htop sorts by PID.
• ✗ Thinking top 'monitors'. It only rereads /proc periodically.

Follow-up

• ? What does `ps -eo pid,ppid,user,cmd,wchan` show, and why do you need the wchan column?
• ? How does top compute the CPU delta between ticks, and where does it get jiffies?
• ? Why are `pgrep` and `pkill` handier than `ps | grep | awk | xargs kill`?

Что отвечать

The SUID bit on a binary tells the kernel to set the process's EUID to the file's owner at launch, not to the calling user. `/usr/bin/passwd` has SUID and is owned by root, so any user can change their own password. passwd runs as root briefly to write to `/etc/shadow`.

Что хотят услышать

A senior should: - tell apart UID (the real one, who launched it) and EUID (the effective one, which permission checks run against) - name the dangers of SUID binaries: a vulnerability in a SUID binary is local root, which is why the CIS benchmark says 'find and audit every SUID binary' - mention `capabilities` as the modern alternative to SUID: grant the process only the capability it needs (CAP_NET_BIND_SERVICE for binding below 1024) instead of all of root - name the `nosuid` mount option as a defense: SUID on /home or /tmp will not take effect

Подводные камни

• ✗ Saying SUID always makes the process root. No, only the EUID changes, and only for a binary owned by root.
• ✗ Not mentioning SGID and the sticky bit, the related mechanisms.
• ✗ Forgetting that SUID is ignored on scripts with a shebang (the kernel refuses to raise privileges for interpreted code).

Follow-up

• ? How do you find every SUID binary in the system with one command?
• ? Why are capabilities better than SUID? Show it with ping as the example.
• ? Why does SUID on a shell script not raise privileges?