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

Ce que c'est

Le manuel de wget définit un code par catégorie d'erreur :

Code	Signification
0	Aucun problème
1	Code d'erreur générique
2	Erreur d'analyse (ligne de commande, .wgetrc, .netrc)
3	Erreur d'E/S sur fichier
4	Échec réseau
5	Échec de vérification SSL
6	Échec d'authentification par nom d'utilisateur/mot de passe
7	Erreurs de protocole
8	Le serveur a renvoyé une réponse d'erreur

Le manuel précise aussi que, hormis 0 et 1, les codes les plus bas sont prioritaires lorsque plusieurs types d'erreur surviennent au cours d'une même exécution.

La table de rsync est plus longue et comprend notamment :

Code	Signification
0	Succès
1	Erreur de syntaxe ou d'utilisation
2	Incompatibilité de protocole
3	Erreurs lors de la sélection des fichiers ou répertoires d'entrée/sortie
5	Erreur au démarrage du protocole client-serveur
10	Erreur d'E/S sur socket
11	Erreur d'E/S sur fichier
12	Erreur dans le flux de données du protocole rsync
23	Transfert partiel dû à une erreur
24	Transfert partiel dû à des fichiers sources disparus
30	Délai dépassé lors de l'envoi/réception de données
35	Délai dépassé en attendant la connexion au démon

Pourquoi c'est important

Le code 24 est celui auquel il ne faut pas réagir de manière excessive : il apparaît dès que rsync constate, pendant l'analyse ou le transfert, qu'un fichier source qu'il avait listé a tout simplement disparu — répertoire de build en cours d'écriture simultanée, journal pivoté en cours d'exécution, fichier temporaire supprimé par un autre processus. Le transfert de tous les autres fichiers est bien allé à son terme. Le code 23 est plus large et peut masquer un vrai problème de permissions ou d'E/S — un chemin source inexistant se termine lui aussi par 23 — et mérite donc plus d'attention que le 24. rsync lui-même qualifie le 24 d'« avertissement » (« warning ») et le 23 d'« erreur » (« error »).

Comment l'appliquer

• Avec wget, branchez la logique sur le code précis avant de relancer : les codes 4 et 7 justifient une nouvelle tentative avec backoff ; les codes 2, 5 et 6 exigent une correction de configuration, pas une nouvelle tentative.
• Avec rsync, traitez un code 24 seul, sur une arborescence source connue pour changer pendant l'exécution (journaux, sorties de build), comme une simple information : consignez-le, mais ne faites pas échouer le job sur le seul code 24.
• Traitez le code 23 de rsync comme un véritable avertissement : relancez avec -v/--stats ou consultez la sortie détaillée (itemized) pour voir quels fichiers ont échoué et pourquoi, avant de décider qu'on peut l'ignorer sans risque.
• Pour les deux outils, conservez le journal de transfert : une exécution ne renvoie qu'un seul code de sortie, même si plusieurs problèmes distincts se sont produits.

Pièges

• Écrire rsync ... || exit 1 dans un script sans distinguer 23 de 24 transforme des disparitions de fichiers en cours d'analyse, courantes et attendues, en faux échecs de pipeline.
• Supposer que les codes de wget sont stables jusque dans les versions très anciennes : le manuel indique lui-même qu'avant la version 1.12, les téléchargements récursifs « would virtually always return 0 » (renvoyaient pratiquement toujours 0), quelles que soient les erreurs rencontrées.
• Via ssh, un échec de connexion se traduit par le code de sortie 255 de rsync (« unexplained error »), qui ne figure pas dans la table de rsync — il faut y voir le 255 propre à ssh.