Тема: exit-codes
-
docker/podman run exit codes: 125, 126, 127, and the signal codes that reach through them
docker run reserves 125, 126 and 127 for failures of Docker itself, an uninvokable command, and a not-found command respectively; any other code is passed through unchanged from the containerized process, including the 128+signal codes (137 for SIGKILL, often OOM; 139 for SIGSEGV; 143 for SIGTERM). The container's own OOMKilled flag, not the bare 137, is the documented way to confirm an out-of-memory kill, though on some cgroup-v2 hosts it reads false even after a kernel OOM kill.
-
find and xargs exit codes: find's coarse 0/>0 versus xargs's 123-127 ladder
find only promises 0 for full success and any value above 0 for an error, deliberately without finer detail, while xargs defines a specific ladder for how the invoked command failed: 123 for an ordinary non-zero exit, 124 for exit 255, 125 for killed-by-signal, 126 for not-invocable, and 127 for not-found. Piping find into xargs means checking two different exit-code philosophies in one pipeline.
-
grep, diff, cmp and test/[: exit code 1 means not-found, not failure
grep, diff, cmp and the test/[ builtin all use the same three-way scale: 0 for a positive result, 1 for a negative result that is not an error, and 2 (or >1) for real trouble. Reading 1 as a script failure is the most common misreading an agent makes with these tools.
-
curl's exit codes: telling a DNS failure from a TLS failure from --fail
curl returns a distinct numeric code for each class of transport failure (name resolution, connection, TLS, timeout) plus a separate code, 22, that only appears when --fail or --fail-with-body is requested for HTTP error statuses. An agent that greps curl's exit code instead of its text can route retries correctly without parsing output.
-
timeout, kill and the 128+signal convention: reading what killed a process from its exit code
GNU timeout uses 124 for its own timeout, 125 for its own internal failure, 126/127 for an uninvokable/missing command, and 137 when it has to escalate to SIGKILL; kill -0 checks whether a process exists without sending a real signal; and the 128+signal-number convention (137 = SIGKILL, 139 = SIGSEGV, 143 = SIGTERM on x86/ARM) lets an agent read the specific cause off a bare exit code.
-
apt-get, dpkg, dnf and zypper exit codes: when 100 means updates, not failure
apt-get uses a flat 0-success/100-error split; dpkg distinguishes a failed check (1) from a fatal usage or system error (2); dnf's check-update repurposes 100 to mean updates ARE available, not an error; and zypper defines a whole range, 100-107, of informational (non-error) exit codes for conditions like a pending reboot (though 104, package not found, and 105, interrupted, mean the action did not happen). Reading any of these as a plain success/fail boolean loses real information.
-
ssh and scp exit codes: 255 is ssh's own failure, anything else is the remote command's
ssh passes through the exit status of the remote command it ran, reserving 255 for a failure of ssh itself (connection refused, authentication failure, host key mismatch) and for a remote command killed by a signal. scp documents only a plain 0-success/nonzero-failure split, so distinguishing local transport trouble from a remote error requires ssh's stderr text, not scp's own code.
-
Windows exit codes beyond pass/fail: robocopy's bitmask, msiexec's installer codes, and $LASTEXITCODE
robocopy encodes several independent facts (files copied, extra files, mismatches, failures) into one number below 8 that must be read as a bitmask, not compared to zero; msiexec returns specific Windows Installer codes where 3010 and 1641 mean success with a pending reboot, not failure; and PowerShell's $LASTEXITCODE is the only reliable way to see a native program's real code, with different rules depending on how the script was invoked.
-
wget and rsync exit codes: rsync's 23 and 24 usually aren't the failure they look like
wget assigns a small fixed code per error class (network, SSL, auth, protocol); rsync's larger table includes 23 (partial transfer due to error) and 24 (partial transfer due to vanished source files), the latter of which commonly just means a file disappeared mid-scan and is not evidence of a broken transfer.
-
git exit codes an agent can rely on: diff --exit-code, ls-remote --exit-code, and bisect run's 125
Most git porcelain commands only document 'non-zero on failure' without a fixed numeric table, but three commands publish an exact, citable contract: git diff/--quiet uses 1 for differences, git ls-remote --exit-code uses 2 for no matching refs, and git bisect run reserves 125 to mean 'skip this commit,' not 'bad.' A conflicted merge is signalled by state (MERGE_HEAD), not a documented number.
-
make, ping and nc: exit codes that quietly don't check what you'd assume
GNU make's exit code 1 from -q means 'a target needs rebuilding,' not failure; ping's exit code 1 means no reply was received (host down, not a broken ping invocation) while 2 means a real usage/error; and openssl s_client documents that a default connection succeeds (exit 0) even when certificate verification failed, unless -verify_return_error is given.
-
systemctl exit codes: is-active, is-enabled, is-failed, and what LSB code 3 means
systemctl's is-active, is-enabled and is-failed subcommands document a simple 0-vs-non-zero contract (in practice returning LSB-style values such as 3 for inactive and 4 for an unknown unit), while systemctl status follows the older LSB init-script convention where 3 means 'not running' rather than an execution error. Reading 3 or 4 as a broken invocation is the main way agents misread systemctl.
-
Exit codes as a contract between scripts and the agent that calls them
An agent that runs a script and moves on based on its exit code needs that code to mean what the shell's own conventions say it means: 0 for success, small positive numbers for the script's own defined failures, 126/127 for a command that could not be run at all, and 128+n for death by signal — and it needs pipefail or PIPESTATUS to see the real code through a pipeline.
Машиночитаемо: JSON