Linux system errors
Timer Expired
Reviewed for reference consistency: August 11, 2026
an alarm() deadline the process set for itself has run out
What 142 Means
The 142 error on the Linux system errors indicates timer expired — an alarm() deadline the process set for itself has run out. This typically occurs due to a program scheduling alarm() as a watchdog and the deadline firing on a hung operation.
Exit code 142 stands for 128 + 14, SIGALRM — a deadline the process armed for itself through alarm() or an interval timer finally ran out, converting an internal watchdog or self-imposed timeout into an exit the shell reports like any other signal death.
How to fix 142
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Put an outside deadline on the command
timeout enforces a limit from outside the process; the resulting exit is 143 unless another signal is chosen, which cleanly separates external limits from the program's own alarm.
timeout 30 ./your_commandWatch timer calls as they happen
A syscall trace filtered to timer calls shows the process arming and resetting its own deadlines.
strace -e trace=alarm,setitimer,nanosleep ./your_program
Technical Background
Code 142 is a deadline made visible. The process called alarm() — or set an interval timer — and the kernel kept the appointment, raising signal 14 when the seconds ran out. The design intent is self-protection: a program that cannot trust its own operations to finish arms a timer so a hang becomes a clean death instead of an eternal stall.
Watchdogs built this way are common around network I/O, where a peer can freeze without closing the connection. The alarm converts an indefinite wait into a bounded one; the resulting exit is the safety net catching, not a bug in itself.
The ambiguity is calibration. A deadline tuned for normal inputs will eventually meet an input that legitimately needs longer, and the watchdog fires on healthy work. Distinguishing protective kills from premature ones means comparing the deadline against the actual duration distribution of the operation it guards.
Common Causes
- A program scheduling alarm() as a watchdog and the deadline firing on a hung operation
- A library or runtime using interval timers internally, expiring during a stall
- An alarm left armed by an earlier code path firing later than expected
Typical Scenarios
- A network client arming a 30-second watchdog around a request and dying when the peer stalled past it
- A batch job setting a self-imposed time limit per record and hitting it on one pathological input
- A library's internal interval timer expiring while the main flow waited on a slow resource
What to Know
The timer's origin is discoverable: a syscall trace shows alarm and timer calls as the program makes them, and the code around them explains what deadline was being protected. An external timeout wrapper, by contrast, leaves exit 143 rather than 142.
Frequently Asked Questions
Common questions about Linux 142 error
The process itself, via alarm() or an interval timer syscall — the kernel never arms timers unprompted. Application code, a library, or the language runtime owns the deadline, and its source code or a syscall trace names it.
timeout sends SIGTERM (exit 143) by default when its deadline passes — the deadline is external, held by another process. Exit 142 means the deadline lived inside the victim: it armed the alarm itself.
Often it is the timer doing precisely its job — a watchdog killing a hung operation is success, not malfunction. It reads as a failure only when the deadline was miscalibrated for the real work.
Related Error Codes
Terminated by User — the process was interrupted by a SIGINT signal
Invalid Exit Argument — script exited with an out-of-range status or terminated by a signal
Termination Request — a polite shutdown signal the process may handle before exiting
Interrupted Call — a signal arrived mid-operation; the call stopped and can simply be retried
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
You have unresolved file conflicts preventing Git from completing the current operation.
You tried to add a remote named 'origin', but one with that name already exists.
Git does not know which remote branch should receive your pushed commits.
You checked out a specific commit, detaching your working directory from the branch history.