Python InterruptedError — What It Means & How to Fix It

What Does This Error Mean?

An InterruptedError means a low-level system call (like reading from a socket or waiting for I/O) was interrupted by a signal before it finished. On most modern Python versions (3.5+) this is handled automatically — system calls are retried after a signal is received. If you still see this error, it is most likely on an older Python version, or you are using low-level socket or OS calls that do not benefit from automatic retry.

Affected Models

Python 3.12
Python 3.11
Python 3.10
Python 3.9
Python 3.8

Common Causes

A Unix signal (such as SIGCHLD or SIGALRM) arriving while a blocking system call is in progress
Using low-level socket operations in Python 3.4 or earlier where automatic retry was not yet implemented
A signal handler being called during a blocking read, write, or wait operation
Using os.read(), os.write(), or socket operations directly without the higher-level wrappers that handle EINTR
Running on a system with frequent signals (such as when using SIGALRM for timeouts)

How to Fix It

First, confirm your Python version. If you are on Python 3.5 or later, most system calls are automatically retried after signals — this error should be very rare.

Run 'python --version' or 'python3 --version' in your terminal. Python 3.5+ implemented PEP 475 which makes most blocking calls immune to EINTR.
If on Python 3.5+ and still seeing this error, check whether you are using raw os.read(), os.write(), or low-level socket methods directly.

Low-level calls like os.read() and os.write() may still raise InterruptedError. Use the higher-level file and socket wrappers instead (open(), socket.makefile()).
Wrap the problematic call in a retry loop that catches InterruptedError and repeats the call.

Example: while True: try: result = blocking_call(); break; except InterruptedError: continue. This manually implements the retry that PEP 475 added automatically.
If you are using SIGALRM for timeouts, consider switching to the 'signal.setitimer' approach or using the 'timeout' parameter available on most socket and subprocess calls.

socket.settimeout(seconds) is cleaner than SIGALRM for network timeouts and does not cause InterruptedError.
Review your signal handlers. If a signal handler does complex work or raises exceptions, it can interfere with blocking operations. Keep signal handlers minimal.

Best practice: in a signal handler, set a flag variable to True. Then check that flag in your main loop rather than doing complex work in the handler.

When to Call a Professional

InterruptedError is uncommon in modern Python 3.5+ and usually indicates low-level code or a very specific environment issue. If you are maintaining legacy code that runs on Python 3.4 or earlier, consult the Python 3.5 migration notes on PEP 475. For complex signal handling scenarios, a developer experienced with Unix system programming can help design the right signal handling architecture.

Frequently Asked Questions

What is PEP 475 and why does it matter for InterruptedError?

PEP 475, introduced in Python 3.5, changed how Python handles the EINTR error from the operating system. Before 3.5, any signal arriving during a blocking call would raise InterruptedError and stop the call. After 3.5, Python automatically retries the system call, making InterruptedError much rarer in everyday code.

Should I add InterruptedError handling to all my network code?

On Python 3.5+, no — it is handled for you in most cases. Add handling only if you are using raw os module calls, supporting older Python versions, or working in an environment with heavy signal usage. For modern code using the socket, http, or requests libraries, InterruptedError handling is already built in.

Is InterruptedError related to keyboard interrupt (Ctrl+C)?

No — pressing Ctrl+C raises KeyboardInterrupt, which is a completely separate exception. InterruptedError comes from Unix signals at the operating system level interrupting a blocking I/O call, not from the user pressing a key. Handle them separately: use except KeyboardInterrupt for Ctrl+C and except InterruptedError for signal-interrupted system calls.