Códigos de saída do wget e do rsync: os códigos 23 e 24 do rsync geralmente não são a falha que parecem

O que é

O manual do wget define um código para cada categoria de erro:

Código	Significado
0	Nenhum problema ocorreu
1	Código de erro genérico
2	Erro de análise (linha de comando, .wgetrc, .netrc)
3	Erro de E/S de arquivo
4	Falha de rede
5	Falha na verificação SSL
6	Falha na autenticação por usuário/senha
7	Erros de protocolo
8	O servidor retornou uma resposta de erro

O manual também observa que, com exceção do 0 e do 1, os códigos de numeração mais baixa têm precedência quando vários tipos de erro ocorrem na mesma execução.

A tabela do rsync é mais longa e inclui, entre outros:

Código	Significado
0	Sucesso
1	Erro de sintaxe ou de uso
2	Incompatibilidade de protocolo
3	Erros ao selecionar arquivos ou diretórios de entrada/saída
5	Erro ao iniciar o protocolo cliente-servidor
10	Erro de E/S no socket
11	Erro de E/S de arquivo
12	Erro no fluxo de dados do protocolo rsync
23	Transferência parcial por erro
24	Transferência parcial por arquivos de origem que desapareceram
30	Timeout no envio/recebimento de dados
35	Timeout aguardando a conexão com o daemon

Por que importa

O código 24 é aquele ao qual não se deve reagir de forma exagerada: ele aparece sempre que o rsync percebe, durante a varredura ou a transferência, que um arquivo de origem que ele já tinha listado simplesmente não existe mais — por exemplo, um diretório de build sendo escrito ao mesmo tempo, um log rotacionado no meio da execução ou um arquivo temporário removido por outro processo. A transferência de todos os outros arquivos foi concluída normalmente. O código 23 é mais abrangente e pode esconder um problema real de permissão ou de E/S — um caminho de origem que não existe de forma alguma também termina em 23 —, por isso merece mais atenção do que o 24. O próprio rsync classifica o 24 como "warning" (aviso) e o 23 como "error" (erro).

Como aplicar

• No wget, ramifique a lógica de acordo com o código específico antes de tentar novamente: os códigos 4 e 7 justificam uma nova tentativa com backoff; os códigos 2, 5 e 6 exigem uma correção de configuração, não uma nova tentativa.
• No rsync, trate um 24 isolado, em uma árvore de origem que se sabe mudar durante a execução (logs, saída de build), como informativo; registre-o em log, mas não faça o job falhar só por causa do 24.
• Trate o 23 do rsync como um aviso real: execute novamente com -v/--stats ou consulte a saída itemizada para ver quais arquivos falharam e por quê, antes de decidir que é seguro ignorá-lo.
• Em ambas as ferramentas, mantenha o log da transferência; uma execução informa um único código de saída, mesmo que vários problemas distintos tenham ocorrido.

Armadilhas

• Escrever rsync ... || exit 1 em scripts, sem distinguir o 23 do 24, transforma eventos rotineiros e esperados de desaparecimento de arquivos durante a varredura em falsas falhas de pipeline.
• Presumir que o código do wget é estável em versões muito antigas: o próprio manual observa que, antes da 1.12, downloads recursivos "would virtually always return 0" (praticamente sempre retornavam 0), independentemente dos erros encontrados.
• Via ssh, uma conexão que falha aparece como saída 255 do rsync ("unexplained error", erro sem explicação), que não consta da tabela do rsync — interprete-o como o 255 do próprio ssh.