timeout, kill und die 128+Signal-Konvention: Aus dem Exit-Code ablesen, was einen Prozess beendet hat

Worum es geht

Das Manual von timeout definiert eine kleine, eigene Abstufung von Exit-Codes, die sich vom Exit-Status des Befehls selbst unterscheidet:

Code	Bedeutung
124	COMMAND hat das Zeitlimit überschritten (und --preserve-status wurde nicht angegeben)
125	der Befehl timeout selbst ist fehlgeschlagen
126	COMMAND wurde gefunden, konnte aber nicht aufgerufen werden
127	COMMAND wurde nicht gefunden
137	COMMAND (oder timeout selbst) hat SIGKILL (128+9) erhalten, typischerweise nachdem ein früheres Signal ignoriert wurde
—	andernfalls wird der Exit-Status von COMMAND unverändert zurückgegeben

--preserve-status ändert dieses Verhalten: timeout beendet sich dann "with the same status as COMMAND, even when the command times out" (mit demselben Status wie COMMAND, selbst wenn das Zeitlimit überschritten wird). Das ist unverzichtbar, wenn der Aufrufer den eigenen Code des umhüllten Programms braucht statt 124.

kill -0 PID sendet überhaupt kein Signal. Das Manual von kill(2) hält fest: "If sig is 0, then no signal is sent, but existence and permission checks are still performed". Damit lässt sich prüfen, ob eine PID existiert und ob ihr ein Signal gesendet werden darf (bei einem Prozess eines anderen Benutzers schlägt der Aufruf mit "Operation not permitted" fehl, obwohl die PID existiert). Die Exit-Codes unterscheiden sich je nach Implementierung: kill aus util-linux liefert 0, 1 oder 64 (Teilerfolg bei mehreren PIDs); das /usr/bin/kill von procps-ng (Debian/Ubuntu) liefert bei Teilerfolg 1; das Bash-Builtin, das Skripte in der Regel verwenden, liefert 0, wenn mindestens ein Signal gesendet wurde. POSIX definiert nur 0 (mindestens ein Signal zugestellt) und >0.

Die Konvention 128+Signal erlaubt es, die Ursache direkt aus einem nackten Exit-Code abzulesen. Auf x86/ARM (die Nummerierung, die laut dem Linux-Signal-Manual auf "most other architectures" gilt):

Signal	Nummer	128+n
SIGHUP	1	129
SIGINT	2	130
SIGQUIT	3	131
SIGABRT	6	134
SIGKILL	9	137
SIGSEGV	11	139
SIGPIPE	13	141
SIGTERM	15	143

Warum es wichtig ist

124 ist kein Absturz, sondern timeout, das seine Aufgabe erfüllt. Wer den Code mit einem Programmfehler verwechselt, lässt Agenten einen hängenden Befehl endlos wiederholen oder einen sauberen Timeout als rätselhaften Bug melden.

So wird es angewendet

• Zuerst auf 124 prüfen; ohne --preserve-status stammt jeder Code ausserhalb von 124–127 und 137 vom Befehl selbst. Mit --preserve-status zeigt sich ein Timeout als 128+Signal (143 beim Standardsignal TERM), nie als 124.
• kill -0 "$pid" (oder kill -0 -- "$pid", um bei negativen Werten sicher zu sein) ausschliesslich als Existenz- und Berechtigungsprüfung in Polling-Schleifen verwenden, nie um tatsächlich etwas zu beenden.
• Endet ein umhüllter Prozess mit einem Code 128+n, 128 abziehen, um das Signal nachzuschlagen, und dann entscheiden, ob dieses Signal erwartbar ist (ein Supervisor sendet SIGTERM beim Herunterfahren) oder nicht (SIGSEGV bei einem echten Absturz).
• timeout --signal=TERM --kill-after=<grace> <duration> cmd bevorzugen, damit ein hängender Prozess unter SIGTERM die Möglichkeit zum Aufräumen erhält, bevor das härtere SIGKILL (137) eintrifft.

Stolpersteine

• Annehmen, Signalnummern seien architekturunabhängig; das Linux-Manual hält ausdrücklich fest, dass SIGBUS, SIGSTKFLT und mehrere weitere Signale sich zwischen x86/ARM, Alpha/SPARC, MIPS und PARISC unterscheiden.
• Den Exit-Code 64 von kill aus util-linux (Teilerfolg bei mehreren PIDs) als vollständigen Fehlschlag behandeln; einige Signale wurden erfolgreich zugestellt.