nohup & disown

Das Problem: SIGHUP beim Terminal-Schließen

Wenn du eine Shell startest, erzeugt der Kernel eine Session mit der Shell als Session-Leader und einem kontrollierenden Terminal (tty). Alle Kommandos, die du in dieser Shell startest, werden Teil dieser Session — egal ob im Vordergrund oder im Hintergrund.

Geht das Terminal-Fenster zu (oder bricht die SSH-Verbindung ab), schickt der Kernel ein SIGHUP an den Session-Leader. Die Shell reagiert darauf, indem sie ihrerseits SIGHUP an alle bekannten Jobs weiterreicht. Der Default-Handler von SIGHUP ist „beenden” — und damit reißen alle Hintergrundprozesse mit.

Drei Werkzeuge unterbrechen diese Kette an unterschiedlichen Stellen: nohup lässt den Prozess SIGHUP von vornherein ignorieren, disown entfernt den Job aus Bash’s Tabelle (Schritt 4 läuft ins Leere), setsid löst den Prozess komplett aus der Session (Schritt 3 erreicht ihn nicht).

nohup — SIGHUP ignorieren

nohup (No Hang-Up) ist das klassische Werkzeug. Es startet ein Programm so, dass das SIGHUP-Signal ignoriert wird — der Prozess hört das Hangup-Signal also gar nicht erst. Zusätzlich kümmert sich nohup um die Standard-Streams: Wenn stdout oder stderr an ein Terminal hängen, leitet es sie automatisch in eine Datei nohup.out (im aktuellen Verzeichnis, oder ersatzweise in ~/nohup.out).

Der klassische Aufruf:

nohup ./long-task.sh &

Wichtig ist die Reihenfolge: nohup muss vor dem Befehl stehen, weil es ein eigenständiges Programm ist, das den Befehl als Argument startet — nicht ein Shell-Builtin, das nachträglich auf einen laufenden Job wirkt. Das & am Ende schickt den Prozess in den Hintergrund; ohne & läuft nohup zwar SIGHUP-immun, blockiert aber das Terminal.

disown — aus der Job-Tabelle entfernen

disown ist ein Bash-Builtin und arbeitet auf einer ganz anderen Ebene als nohup: Es entfernt einen bereits laufenden Job aus der Job-Tabelle der Shell. Damit weiß die Shell beim Beenden nicht mehr, dass dieser Prozess existiert — und reicht beim Empfang von SIGHUP nichts mehr an ihn weiter.

Die wichtigsten Varianten:

disown %1
disown -h %1
disown -a
disown

disown ist nur sinnvoll auf bereits laufenden Background-Jobs — also Befehlen, die mit & gestartet oder per Strg + Z und bg in den Hintergrund gelegt wurden. Auf einen Vordergrund-Prozess wirkt es nicht, und vor dem Start eines Befehls geht es ebenfalls nicht. Hat man nohup vergessen, ist disown der nachträgliche Rettungsanker.

setsid — eigene Session starten

setsid geht noch einen Schritt weiter: Es startet den Befehl in einer neuen Session, mit dem neuen Prozess als Session-Leader. Damit ist er kein Mitglied der Shell-Session mehr — und das SIGHUP, das die Shell beim Schließen verteilt, erreicht ihn überhaupt nicht.

setsid ./long-task.sh > log 2>&1 < /dev/null &

Das ist die Methode, mit der echte Daemons früher von Hand gebaut wurden: fork(), im Kind setsid(), alle Datei-Deskriptoren schließen, neu öffnen auf /dev/null oder eine Logdatei. Heute übernimmt das systemd, aber für ein robustes „Skript einfach detached starten” ist setsid die direkteste Lösung.

Vergleich der vier Werkzeuge

& allein gehört der Vollständigkeit halber dazu — es ist kein Detachment-Mechanismus, nur eine Anweisung an die Shell, nicht zu warten. Der Job bleibt in der Job-Tabelle und stirbt mit ihr.

In der Praxis kombiniert man oft: nohup und & zusammen, oder setsid mit expliziter Umlenkung aller drei FDs. disown ist der nachträgliche Notfallplan.

stdin, stdout und stderr trennen

Selbst SIGHUP-Schutz reicht nicht für ein wirklich detached Programm. Solange der Prozess seine Datei-Deskriptoren 0, 1 und 2 noch ans Terminal hat, hängt er an der TTY. Wird die TTY beim Schließen des Fensters abgebaut, bekommen Schreibversuche auf stdout ein SIGPIPE oder einen EIO-Fehler — und der Prozess stirbt trotzdem.

Die saubere Variante schließt alle drei FDs explizit:

nohup ./long-task.sh > out.log 2>&1 < /dev/null &

nohup lenkt automatisch nur stdout um, wenn es ein Terminal ist — stderr und stdin bleiben unangetastet. Wer kein nohup.out will und sicheres Verhalten beim Schließen des Terminals braucht, leitet alle drei explizit um. Bei setsid ist diese Umleitung Pflicht, sonst killt der TTY-Abbau den Prozess trotz neuer Session.

Praxis-Patterns

Die folgenden Idiome decken praktisch alle Fälle ab, in denen man einen Befehl vom Terminal lösen will. Jedes hat seine Stärke.

Klassisch mit nohup:

nohup ./long-task.sh > log 2>&1 &

Einfachster, weitverbreiteter Aufruf. SIGHUP wird ignoriert, Output landet in log, stderr im selben Strom. Funktioniert in jeder POSIX-Shell und ist die Standard-Empfehlung in Tutorials.

Nachträglich mit disown:

./long-task.sh > log 2>&1 &
disown

Wenn man nohup vergessen hat oder es nachträglich entscheiden will: Job läuft schon im Hintergrund, disown ohne Argument entfernt den zuletzt gestarteten Job aus der Tabelle. Geht nur in der laufenden Shell, nicht später aus einer anderen Sitzung.

Vollständig detached mit setsid:

setsid ./long-task.sh > log 2>&1 < /dev/null &

Robusteste Variante: neuer Session-Leader, alle drei FDs umgelenkt. Der Prozess überlebt selbst harte SSH-Disconnects und ist von der ursprünglichen Shell vollständig entkoppelt. jobs zeigt ihn nicht mehr an — verwalten musst du ihn jetzt über die PID.

Mit User-Wechsel:

sudo -u www-data nohup ./serve.sh > /var/log/serve.log 2>&1 &

Klassisches Pattern, wenn ein Service unter einem Service-User laufen soll, aber kein systemd-Unit existiert. sudo -u wechselt den Effective User, nohup schützt vor SIGHUP. Für Produktion bleibt ein systemd-Service trotzdem die saubere Lösung.

Stop-Wait-Idiom:

nohup ./build.sh > log 2>&1 &
wait

Praktisch für Skripte: Mehrere Tasks parallel starten, dann mit wait auf alle warten. Der nohup-Anteil ist dabei nicht zwingend, sorgt aber dafür, dass die Tasks auch dann sauber weiterlaufen, wenn das umgebende Skript zwischendurch SIGHUP bekommt.

zsh-Spezialität &!:

./long-task.sh > log 2>&1 &!

Nur in zsh: Der Operator &! startet im Hintergrund und ruft disown in einem Rutsch. Bash kennt das nicht — dort braucht es zwei separate Befehle.

Weiterführende Ressourcen

Externe Quellen

• man 1 nohup (man7.org) — Referenz zum nohup-Kommando aus den GNU coreutils
• Bash Reference: Job Control Builtins — disown, jobs, fg, bg im offiziellen Bash-Manual
• man 1 setsid (man7.org) — Referenz zum setsid-Kommando aus util-linux
• Arch Wiki: Daemon — Hintergrund zu klassischen und modernen Daemonisierungs-Verfahren
• BashFAQ #068: How do I run a command, and have it abort if a certain condition is met? — typische Detach-Idiome aus der Bash-Community

Verwandte Artikel

• Jobs, fg und bg — Job-Steuerung in der Shell verstehen
• Signale unter Linux — SIGHUP, SIGTERM und Co. im Detail
• Prozess-Modell — PID, Sessions und Prozess-Gruppen
• Terminal-Multiplexer — tmux und screen als Alternative zu nohup
• systemd-Timer und Services — die saubere Lösung für dauerhafte Daemons