Códigos de salida de wget y rsync: los códigos 23 y 24 de rsync no suelen ser el fallo que parecen

Qué es

El manual de wget define un código por cada categoría de error:

Código	Significado
0	No se produjeron problemas
1	Código de error genérico
2	Error de análisis (línea de comandos, .wgetrc, .netrc)
3	Error de E/S de archivos
4	Fallo de red
5	Fallo de verificación SSL
6	Fallo de autenticación con usuario/contraseña
7	Errores de protocolo
8	El servidor devolvió una respuesta de error

El manual indica además que, salvo el 0 y el 1, los códigos de numeración más baja tienen prioridad cuando en una misma ejecución se producen varios tipos de error.

La tabla de rsync es más larga e incluye, entre otros, estos códigos:

Código	Significado
0	Éxito
1	Error de sintaxis o de uso
2	Incompatibilidad de protocolo
3	Errores al seleccionar archivos o directorios de entrada/salida
5	Error al iniciar el protocolo cliente-servidor
10	Error de E/S en el socket
11	Error de E/S de archivos
12	Error en el flujo de datos del protocolo rsync
23	Transferencia parcial por error
24	Transferencia parcial por desaparición de archivos de origen
30	Tiempo de espera agotado en el envío/recepción de datos
35	Tiempo de espera agotado esperando la conexión con el daemon

Por qué importa

El código 24 es el que conviene no tomar como una alarma: aparece siempre que rsync detecta, durante el análisis o la transferencia, que un archivo de origen que ya había listado ha dejado de existir. Ocurre, por ejemplo, con un directorio de compilación en el que se escribe de forma concurrente, un log rotado a mitad de la ejecución o un archivo temporal que borra otro proceso. La transferencia de todos los demás archivos se completó. El código 23 es más amplio y puede ocultar un problema real de permisos o de E/S (una ruta de origen que no existe en absoluto también termina en 23), por lo que merece más atención que el 24. El propio rsync califica el 24 de «warning» (aviso) y el 23 de «error».

Cómo aplicarlo

• En wget, decide según el código concreto antes de reintentar: los códigos 4 y 7 merecen un reintento con backoff; los códigos 2, 5 y 6 requieren corregir la configuración, no reintentar.
• En rsync, trata un 24 aislado sobre un árbol de origen que se sabe que cambia durante la ejecución (logs, resultados de compilación) como algo informativo: regístralo, pero no hagas fallar el trabajo solo por un 24.
• Trata el 23 de rsync como un aviso real: vuelve a ejecutar con -v/--stats o revisa la salida detallada por elemento para ver qué archivos fallaron y por qué antes de decidir que se puede ignorar.
• En ambas herramientas, conserva el log de la transferencia: una ejecución informa de un único código de salida aunque se hayan producido varios problemas distintos.

Trampas

• Escribir en un script rsync ... || exit 1 sin distinguir el 23 del 24 convierte eventos rutinarios y esperables, como la desaparición de un archivo durante el análisis, en falsos fallos del pipeline.
• Suponer que los códigos de wget son estables en versiones muy antiguas: el propio manual señala que, antes de la 1.12, las descargas recursivas "would virtually always return 0" (casi siempre devolvían 0) independientemente de los errores encontrados.
• Con ssh, una conexión fallida se manifiesta como código de salida 255 de rsync ("unexplained error", error sin explicación), que no figura en la tabla de rsync: interprétalo como el 255 propio de ssh.