Linux system errors
Interrupted Call
Reviewed for reference consistency: August 11, 2026
a signal arrived mid-operation; the call stopped and can simply be retried
What 4 Means
The 4 error on the Linux system errors indicates interrupted call — a signal arrived mid-operation; the call stopped and can simply be retried. This typically occurs due to a signal (timer, control, or user-defined) delivered while a blocking syscall was in progress.
Exit code 4 corresponds to EINTR, 'Interrupted system call'. It occupies a special place among error codes: nothing actually failed. A signal arrived while the process waited in a slow syscall — a read, an accept, a sleep — and the kernel broke the wait so the signal could be handled. The operation stopped; whether it should restart is the caller's decision.
How to fix 4
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.
See the interruption in the syscall stream
A full trace filtered for interrupted calls shows which syscall stopped and what signal broke it.
strace -o trace.log ./your_command 2>&1 || grep -i intr trace.logRetry the interrupted operation
A bounded retry loop treats EINTR as what it is — a pause, not a failure — and simply calls again.
for i in 1 2 3; do ./your_command && break; sleep 1; done
Technical Background
EINTR is the closest thing to a non-failure in the errno family. The sequence behind it is ordinary: a process sits in a blocking call, a signal arrives, and the kernel must run the handler now — so it breaks the call out. The syscall returns -1 with errno 4, the handler does its work, and the world continues. The only code that experiences a problem is code that assumed blocking calls never return early.
That assumption is where bugs live. An accept loop without EINTR handling exits on the first timer signal; a read loop around a terminal treats a window resize as I/O failure. The fix pattern is uniform and tiny: on EINTR, call again. Restarting is always safe because the interrupted call made no progress to undo.
A syscall trace makes the whole story visible: the interrupted call, the signal that broke it, and whether the code retried — all in consecutive lines.
Common Causes
- A signal (timer, control, or user-defined) delivered while a blocking syscall was in progress
- A debugger or tracer attaching to the process and interrupting a wait
- Retry logic missing around syscalls the code expected to block indefinitely
Typical Scenarios
- A server's accept loop returning with EINTR after a signal handler ran, when the loop lacked a retry
- A long read from a pipe or terminal cut short by a timer signal the process armed
- A debugger attaching to a live process and briefly interrupting its blocking waits
What to Know
The diagnosis is usually about who sent the signal rather than the call that stopped: a signal trace alongside the syscall stream shows both. Code that treats exit 4 as retryable almost always survives; code that exits on it points at the missing loop.
Frequently Asked Questions
Common questions about Linux 4 error
No data was lost and nothing malfunctioned — the call was interrupted so a signal could run its handler. Well-built code around slow syscalls treats EINTR as a retry hint, not a failure.
The signal API lets a handler request automatic restart (SA_RESTART), and even then some calls never restart by design. Libraries that must remain signal-safe code explicit retry loops instead of relying on the flag.
Attaching interrupts the tracee's blocking syscalls so the stop can take effect. Programs whose syscall loops lack EINTR handling surface the interruption as exit 4 right at that moment.
Related Error Codes
Broken Pipe — the process wrote into a pipe whose reader is already gone
Invalid Argument — a syscall received a malformed or self-contradictory parameter
Connection Hangup — the controlling terminal closed; daemons repurpose it as a config-reload trigger
Timer Expired — an alarm() deadline the process set for itself has run out
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.