Check: Linux, processes in depth

fork spawns a child process as a copy of the parent: a new PID, the same memory, and the same open files. exec replaces the code, data, and stack inside an already existing process, and the PID stays the same. A shell runs commands with a two-step combo: first fork, then exec in the child.

In D, the process is waiting for a disk or network filesystem operation to finish. Signals can't reach it until the operation completes, so even kill -9 queues up. S is also a sleep, but any signal interrupts it. T means paused after SIGSTOP or Ctrl+Z, and SIGCONT lifts it.

Only for SIGKILL and SIGSTOP can a process not install its own handler or ignore them. The kernel carries them out itself, bypassing the process's code: one guaranteed to terminate it, the other guaranteed to stop it. For every other signal, including SIGTERM and SIGINT, the process is free to respond however it wants.

Without a number, kill sends SIGTERM (15). That's a polite request to quit: the process can catch it, clean up, and exit, or it can ignore it entirely. The right order is: SIGTERM first, wait, and only if the process is well and truly stuck, kill -9. Signals are useless against a zombie anyway, it has already finished.

A zombie's memory and files were already freed when it finished. All that's left in the process table is an entry with the PID and exit code, and the parent's wait() removes it. kill -9 has no effect on a zombie. If the parent never calls wait(), the only fix is stopping the parent itself: its children get adopted by PID 1, which cleans them up.

Orphaned children in a container get adopted by PID 1. If that's the application, and it never calls wait(), the adopted processes stay zombies after they die. docker run --init puts a small init (tini) at PID 1, and all it does is clean up other processes' zombies. pid_max only delays the moment PIDs run out, and kill -9 doesn't touch zombies.

When a session drops, the shell gets SIGHUP and passes it on to its jobs. nohup runs the command with SIGHUP ignored, and if its output was going to the terminal, it appends it to nohup.out instead. nohup doesn't give you a restart after a crash, that's systemd's job. That's why a long-running service gets set up as a unit, and nohup is left for one-off tasks.