Exercise 1: Why Jobs Die When SSH Drops — and Why Screen Saves Them — Possible Solution
======================================================================================

Explanation:

When you log in over SSH, sshd creates a pseudo-terminal for your
session. Your shell runs attached to that terminal, and every job the
shell starts is attached to it too.

If the network connection breaks, the terminal "hangs up". The system
sends the SIGHUP (hang-up) signal to the shell, and the shell passes
SIGHUP on to the jobs it started. Most programs react to SIGHUP by
exiting, so the long-running command stops part-way through.

Inside screen, the command isn't attached to the SSH session's
terminal at all. A background screen server process owns its own
pseudo-terminals, and the shell and command run inside one of those.
What you see over SSH is only a screen *client* connected to that
server. When the connection drops, the client disappears, but the
server and the terminal it owns are untouched, so nothing sends SIGHUP
to the command. It keeps running, and you can reattach later.

WHY THIS WORKS AS AN ANSWER
------------------------------
It names the actual mechanism (the terminal hang-up and the SIGHUP
signal) rather than just saying "the job gets killed", and it explains
screen's protection in terms of *which* terminal the job belongs to —
the key idea behind the whole course.