Sujet : exit-codes
-
Codes de sortie de docker/podman run : 125, 126, 127 et les codes de signal qui les traversent
docker run réserve 125, 126 et 127 respectivement aux échecs de Docker lui-même, à une commande non invocable et à une commande introuvable ; tout autre code est transmis tel quel depuis le processus conteneurisé, y compris les codes 128+signal (137 pour SIGKILL, souvent un OOM ; 139 pour SIGSEGV ; 143 pour SIGTERM). Pour confirmer un kill par manque de mémoire, la documentation indique le drapeau OOMKilled du conteneur, et non le seul code 137, bien qu'il reste à false sur certains hôtes cgroup v2 même après un kill OOM du noyau.
-
Codes de sortie de find et xargs : le 0/>0 grossier de find face à l'échelle 123-127 de xargs
find ne garantit que 0 en cas de succès complet et une valeur supérieure à 0 en cas d'erreur, volontairement sans plus de détail, alors que xargs définit une échelle précise pour l'échec de la commande lancée : 123 pour une sortie non nulle ordinaire, 124 pour la sortie 255, 125 pour une commande tuée par un signal, 126 pour une commande non exécutable et 127 pour une commande introuvable. Chaîner find et xargs oblige à vérifier deux logiques différentes de codes de sortie dans un même pipeline.
-
grep, diff, cmp et test/[ : le code de sortie 1 signifie « non trouvé », pas « échec »
grep, diff, cmp et la commande interne test/[ suivent la même échelle à trois niveaux : 0 pour un résultat positif, 1 pour un résultat négatif qui n'est pas une erreur, et 2 (ou supérieur à 1) pour un vrai problème. Interpréter 1 comme l'échec d'un script est l'erreur de lecture la plus fréquente d'un agent avec ces outils.
-
Codes de sortie de curl : distinguer une erreur DNS, une erreur TLS et un échec dû à --fail
curl renvoie un code numérique distinct pour chaque classe d'échec de transport (résolution de nom, connexion, TLS, délai dépassé), ainsi qu'un code à part, le 22, qui n'apparaît que si --fail ou --fail-with-body est demandé pour les statuts HTTP d'erreur. Un agent qui s'appuie sur le code de sortie de curl plutôt que sur son texte peut router correctement les nouvelles tentatives sans analyser la sortie.
-
timeout, kill et la convention 128+signal : identifier ce qui a tué un processus grâce à son code de sortie
GNU timeout utilise 124 pour son propre délai dépassé, 125 pour sa propre défaillance interne, 126/127 pour une commande non exécutable ou introuvable, et 137 en cas d'escalade vers SIGKILL. kill -0 vérifie qu'un processus existe sans envoyer de vrai signal, et la convention 128+numéro de signal (137 = SIGKILL, 139 = SIGSEGV, 143 = SIGTERM sur x86/ARM) permet de lire la cause précise à partir d'un simple code de sortie.
-
Codes de sortie d'apt-get, dpkg, dnf et zypper : quand 100 signale des mises à jour et non un échec
apt-get applique un découpage binaire : 0 pour le succès, 100 pour l'erreur. dpkg distingue une vérification négative (1) d'une erreur fatale d'usage ou système (2). Avec check-update de dnf, 100 signifie que des mises à jour SONT disponibles, et non une erreur. zypper définit toute une plage de codes informatifs (qui ne sont pas des erreurs), de 100 à 107, pour des situations comme un redémarrage en attente, mais 104 (paquet introuvable) et 105 (interruption) indiquent que l'action n'a pas eu lieu. Lire ces codes comme un simple booléen succès/échec fait perdre une information réelle.
-
Codes de sortie de ssh et scp : 255 signale un échec de ssh lui-même, tout autre code vient de la commande distante
ssh renvoie le code de sortie de la commande distante exécutée et réserve 255 aux échecs de ssh lui-même (connexion refusée, échec d'authentification, clé d'hôte non concordante) ainsi qu'aux commandes distantes tuées par un signal. La documentation de scp ne distingue que 0 (succès) et non nul (échec) ; pour différencier un problème de transport local d'une erreur distante, il faut donc lire la sortie d'erreur de ssh, et non le code de scp.
-
Codes de sortie Windows au-delà de réussite/échec : le masque de bits de robocopy, les codes Windows Installer de msiexec et $LASTEXITCODE
robocopy regroupe plusieurs faits indépendants (fichiers copiés, fichiers en trop, divergences, échecs) dans un seul nombre inférieur à 8, à lire comme un masque de bits et non à comparer à zéro ; msiexec renvoie des codes précis de Windows Installer, où 3010 et 1641 signalent une réussite avec redémarrage en attente, et non un échec ; enfin, $LASTEXITCODE est le seul moyen fiable de connaître le code réel d'un programme natif dans PowerShell, avec des règles qui varient selon le mode d'appel du script.
-
Codes de sortie de wget et rsync : les codes 23 et 24 de rsync ne sont généralement pas l'échec qu'ils semblent être
wget attribue un petit code fixe à chaque classe d'erreur (réseau, SSL, authentification, protocole) ; la table de rsync, plus étendue, comprend 23 (transfert partiel dû à une erreur) et 24 (transfert partiel dû à des fichiers sources disparus), ce dernier signifiant couramment qu'un fichier a disparu en cours d'analyse, et ne prouvant pas que le transfert soit défaillant.
-
Codes de sortie de git fiables pour un agent : diff --exit-code, ls-remote --exit-code et le code 125 de bisect run
La plupart des commandes porcelain de git documentent seulement un « code non nul en cas d'échec », sans table numérique fixe. Trois commandes publient toutefois un contrat précis et citable : git diff/--quiet renvoie 1 en cas de différences, git ls-remote --exit-code renvoie 2 si aucune référence ne correspond, et git bisect run réserve 125 pour dire « ignorer ce commit », et non « mauvais ». Un merge en conflit se détecte par son état (MERGE_HEAD), pas par un code documenté.
-
make, ping et nc : des codes de sortie qui, discrètement, ne vérifient pas ce qu'on croit
Avec -q, le code de sortie 1 de GNU make signifie « une cible doit être reconstruite », pas un échec ; pour ping, 1 signifie qu'aucune réponse n'est arrivée (hôte inaccessible, et non un appel de ping erroné) et 2 une vraie erreur d'utilisation ou autre ; et openssl s_client documente qu'une connexion par défaut réussit (code 0) même si la vérification du certificat a échoué, sauf avec -verify_return_error.
-
Codes de retour de systemctl : is-active, is-enabled, is-failed et signification du code LSB 3
Les sous-commandes is-active, is-enabled et is-failed de systemctl documentent un contrat simple (0 ou non nul), avec en pratique des valeurs de type LSB comme 3 pour inactif et 4 pour une unité inconnue. systemctl status suit l'ancienne convention des scripts init LSB, où 3 signifie « pas en cours d'exécution » et non une erreur d'exécution. Lire 3 ou 4 comme un appel défectueux est la principale cause d'erreur d'interprétation de systemctl par les agents.
-
Codes de sortie : un contrat entre les scripts et l'agent qui les appelle
Un agent qui exécute un script et décide de la suite d'après son code de sortie doit pouvoir se fier aux conventions du shell : 0 pour le succès, de petits entiers positifs pour les échecs définis par le script, 126/127 pour une commande impossible à lancer et 128+n pour une mort par signal. Il lui faut aussi pipefail ou PIPESTATUS pour obtenir le vrai code à travers un pipeline.
Lisible par machine : JSON