wget and rsync exit codes: rsync's 23 and 24 usually aren't the failure they look like

What it is

wget's manual defines one code per error category:

Code	Meaning
0	No problems occurred
1	Generic error code
2	Parse error (command line, .wgetrc, .netrc)
3	File I/O error
4	Network failure
5	SSL verification failure
6	Username/password authentication failure
7	Protocol errors
8	Server issued an error response

The manual also notes that, except for 0 and 1, lower-numbered codes take precedence when several error types occur in the same run.

rsync's table is longer and includes, among others:

Code	Meaning
0	Success
1	Syntax or usage error
2	Protocol incompatibility
3	Errors selecting input/output files or directories
5	Error starting client-server protocol
10	Error in socket I/O
11	Error in file I/O
12	Error in the rsync protocol data stream
23	Partial transfer due to error
24	Partial transfer due to vanished source files
30	Timeout in data send/receive
35	Timeout waiting for daemon connection

Why it matters

Code 24 is the one to not overreact to: it fires whenever rsync notices, while scanning or transferring, that a source file it had listed is simply gone — a build directory being written concurrently, a log rotated mid-run, a temp file cleaned up by another process. The transfer of every other file still completed. Code 23 is broader and can hide a real permission or I/O problem — a source path that does not exist at all also ends in 23 — so it deserves more scrutiny than 24. rsync itself labels 24 a "warning" and 23 an "error".

How to apply

• For wget, branch on the specific code before retrying: codes 4 and 7 are worth a retry with backoff; codes 2, 5 and 6 need a configuration fix, not a retry.
• For rsync, treat a bare 24 on a source tree known to change during the run (logs, build output) as informational; log it but do not fail the job on 24 alone.
• Treat rsync 23 as a real warning: re-run with -v/--stats or check the itemized output to see which files failed and why before deciding it is safe to ignore.
• For both tools, keep the transfer log; a run reports a single exit code even though several distinct problems occurred.

Pitfalls

• Scripting rsync ... || exit 1 without distinguishing 23 from 24 turns routine, expected vanish-mid-scan events into false pipeline failures.
• Assuming wget's code is stable across very old versions: the manual itself notes that before 1.12, recursive downloads "would virtually always return 0" regardless of errors encountered.
• Over ssh, a failed connection surfaces as rsync exit 255 ("unexplained error"), which is not in rsync's table — read it as ssh's own 255.