timeout, kill et la convention 128+signal : identifier ce qui a tué un processus grâce à son code de sortie

Ce que c'est

Le manuel de timeout définit une petite échelle de codes spécifiques, distincts du code de sortie propre à la commande :

Code	Signification
124	COMMAND a dépassé le délai (et --preserve-status n'a pas été donné)
125	la commande timeout elle-même a échoué
126	COMMAND a été trouvée mais n'a pas pu être invoquée
127	COMMAND est introuvable
137	COMMAND (ou timeout lui-même) a reçu SIGKILL (128+9), généralement après avoir ignoré un signal précédent
—	sinon, le code de sortie propre à COMMAND est renvoyé tel quel

--preserve-status modifie ce comportement : timeout « exit with the same status as COMMAND, even when the command times out » (se termine avec le même code que COMMAND, même lorsque la commande dépasse le délai), ce qui est indispensable lorsque l'appelant a besoin du code du programme encapsulé plutôt que de 124.

kill -0 PID n'envoie aucun signal : le manuel de kill(2) indique « If sig is 0, then no signal is sent, but existence and permission checks are still performed » (si sig vaut 0, aucun signal n'est envoyé, mais les vérifications d'existence et de permission sont tout de même effectuées). La commande permet donc de savoir si un PID existe et s'il peut recevoir un signal (pour le processus d'un autre utilisateur, elle échoue avec « Operation not permitted » alors que le PID existe). Les codes de sortie varient selon l'implémentation : le kill d'util-linux renvoie 0, 1 ou 64 (succès partiel sur plusieurs PID) ; le /usr/bin/kill de procps-ng (Debian/Ubuntu) renvoie 1 en cas de succès partiel ; la commande interne de bash, que les scripts utilisent en général, renvoie 0 si au moins un signal a été envoyé. POSIX ne définit que 0 (au moins un signal délivré) et une valeur >0.

La convention 128+signal permet de lire la cause à partir d'un simple code de sortie. Sur x86/ARM (la numérotation utilisée par « most other architectures » (la plupart des autres architectures) selon le manuel des signaux de Linux) :

Signal	Numéro	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

Pourquoi c'est important

124 n'indique pas un plantage : c'est timeout qui fait son travail. Si un agent le confond avec une défaillance du programme, il relance indéfiniment une commande bloquée ou signale comme un bug mystérieux un simple dépassement de délai normal.

Comment l'appliquer

• Testez d'abord 124 ; sans --preserve-status, tout code autre que 124 à 127 et 137 provient de la commande elle-même. Avec --preserve-status, un dépassement de délai apparaît sous la forme 128+signal (143 pour TERM, le signal par défaut), jamais 124.
• Utilisez kill -0 "$pid" (ou kill -0 -- "$pid" pour se prémunir contre les valeurs négatives) uniquement comme sonde d'existence et de permission dans les boucles d'interrogation, jamais pour terminer réellement quoi que ce soit.
• Lorsqu'un processus encapsulé se termine avec un code 128+n, soustrayez 128 pour retrouver le signal, puis déterminez si ce signal est attendu (un superviseur envoyant SIGTERM pendant l'arrêt) ou non (SIGSEGV dû à un vrai plantage).
• Préférez timeout --signal=TERM --kill-after=<grace> <duration> cmd : un processus bloqué a ainsi la possibilité de faire le ménage après SIGTERM avant l'arrivée du SIGKILL, plus brutal (137).

Pièges

• Supposer que les numéros de signaux sont indépendants de l'architecture ; le manuel de Linux précise explicitement que SIGBUS, SIGSTKFLT et plusieurs autres diffèrent entre x86/ARM, Alpha/SPARC, MIPS et PARISC.
• Traiter le code de sortie 64 du kill d'util-linux (succès partiel sur plusieurs PID) comme un échec complet, alors que certains signaux ont bien été délivrés.