A long-running command you started in an interactive SSH session keeps dying whenever the connection drops. Which signal kills it, what makes the kernel send that signal, and how would you start the job so it survives?

## The symptom You start a build, an import or a long `rsync` over SSH, your laptop sleeps or the Wi-Fi flaps, and when you reconnect the work is gone with no error of its own. Nothing crashed. The job was signalled. ## Where the signal comes from When you log in over SSH, `sshd` allocates a pseudo-terminal and starts your shell on it. That shell becomes a **session leader**, and the pseudo-terminal becomes the session's **controlling terminal**. Commands you run become process groups within that session, one of which is the terminal's foreground process group at any moment. When the connection drops, the far end of that pseudo-terminal is closed — a *hangup*. The kernel's response is defined: it sends SIGHUP to the controlling process of the session, which is your shell. An interactive shell that receives SIGHUP normally relays it to the jobs it still owns before exiting. Either way, the signal lands on your long-running command. SIGHUP's default action is to terminate the process. Your job installed no handler for it, so it dies quietly — no core dump, no message of its own, which is why nothing in its log explains anything. ## The two escapes, and how they differ There are exactly two mechanisms, and interviewers like this question because candidates often conflate them. **Ignore the signal.** `nohup` sets SIGHUP's disposition to `SIG_IGN` and then execs your command. This works because of a rule in the signal model: across `exec`, handlers are reset to the default, but a signal that is *ignored* stays ignored. So the new program starts life immune to SIGHUP without knowing anything about it. The job stays in the same session — it is simply deaf to the hangup. ```bash nohup ./import.sh > import.log 2>&1 & ``` `nohup` also redirects standard output to a file named `nohup.out` if you have not redirected it yourself, precisely because the terminal is about to vanish. **Leave the session.** `setsid` runs the command in a brand-new session with no controlling terminal at all. There is now no terminal to hang up, so the kernel never generates SIGHUP for it. This is the same move a classic daemon makes when it detaches from its launching shell. A terminal multiplexer such as `tmux` or `screen` is the third practical answer and is really a variant of the second: the multiplexer server keeps running on the host with its own pseudo-terminals, and your SSH client is merely attached to it. When the connection drops, the client goes away and the server — with your shell and jobs inside it — does not. This is the option to reach for when you want to *come back* to an interactive session rather than just survive. ## The trap after you survive Surviving the hangup is not the same as still working. Your job's standard output and standard error may still point at the pseudo-terminal that no longer exists; writes to a hung-up terminal fail with `EIO`, and a program that treats a failed write as fatal will die anyway a moment later. That is why every one of these recipes redirects output to a file and redirects stdin from `/dev/null`. If your job asks for input after the terminal is gone, it gets an error, not a prompt. ## Why daemons reuse SIGHUP A daemon has deliberately detached from any controlling terminal, so it can never receive a genuine hangup — the signal is unused for it. That freed it up for a long-standing convention: SIGHUP means "re-read your configuration and reopen your log files without restarting". This is why log-rotation tooling signals daemons rather than restarting them, and it is why a daemon must actually install a handler for SIGHUP: if it does not, the default action still applies and a well-meant reload becomes an outage. ## What an interviewer is checking The named signal is the easy half. The half that separates people is knowing *who* generates it and *why* — that it comes from the terminal layer and the session, not from `sshd` deciding to be tidy — and being able to say which of `nohup` and `setsid` changes the disposition and which changes the session. Getting that pair the wrong way round is the standard tell.