I Understand that EINTR is an error which so-called interruptible system calls may return. My question is where does the signal that causes EINTR come from?

I faced this quite often when using fnctl in Python. I did not issue any interrupting commands such as ctrl + c.

  • The interpretation is different: it is about getting quick results on asyncronous calls. So instead of pushing kernel in WAIT state, you return with what you already have. Else kernel WAIT, and possibly get time to an other process, until an (hardware) interrupt will come (e.g. disk has read data and put it in memory), or network packet in queue. System calls cannot be stopped in the middle of processing, but only on few places. Sep 27 at 7:35
  • Thanks for the explanation @Giacomo . But I would like to know what is the "interrupted signal". Where does it come from? Sep 27 at 7:44
  • "Interrupts" are mostly hardware thing: one (usually more) conductors which go to the CPU. The most common it is a timer. hundreds time per second it will set it, so kernel will be executed in the middle of the processes, and new processes will be executed (so to simulate a multi0-tasking operating system). On some machine keyboard will call an interrupt (but kernel may just queue it for later) on some machine/architectures keys are checked frequently. Note: keyboard controller may send a different interrupt if you press Control-Alt-Delete. Your question is about OS design (not much python) Sep 27 at 8:34
  • Does your your program have any signal handlers installed? Can you describe the circumstances in which you you are seeing EINTR? There is no "interrupted signal". Various system calls are interruptible by any one of a number of signals (that trigger the execution of signal handlers). EINTR can even occur in some cases when no signal handler is involved. Read the signal(7) manual page carefully, especially the section the subsections "Interruption of system calls and library functions by signal handlers" and "Interruption of system calls and library functions by stop signals".
    – mtk
    Sep 27 at 23:29
  • @mtk: EINTR is not a signal. I interpret the question as: why Control-C will not cause errno code EINTR on any system calls (or which signal will cause EINTR errno). @ chewing gum: is it the right interpretation? Sep 28 at 7:35

1 Answer 1


Signals that cause a system call to return EINTR come from where signals normally come from. The behavior you describe can be caused by any signal that is caught by a signal handler.

I interpret your question that you have a concrete situation where your blocking system calls are interrupted by signals you have been unable to find the cause for. As a clue you wrote that these mysterious signals typically occur when you are using the fcntl system call. The fcntl system call can be used to notify the process of events such as changes in the file system. These events are reported as signals. I can't give a more specific answer without knowing more what your code does. Check what you are using fcntl for.

  • fnctl in my Python script is used to issue command to SSD drive on Linux Sep 30 at 16:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .