Interrupted System Call

[Darkie]

I was working at my system, when, during some test, it started giving the following error:

Error: Interrupted system call
at Socket._ioevents (/path/node_modules/zmq/lib/index.js:144:22)
at Socket._flush (/path/node_modules/zmq/lib/index.js:273:23)

I have NO idea where this comes from since my system is very big and has a lot of hooks to the ZMQ binding for NodeJS. Moreover I've never had such error, and I have not touched the ZMQ part of the system since ages.
Maybe you can tell me what's going on with this?

[Darkie]

I think my problem is related to this:

"In 2.0, ZeroMQ would ignore any interrupted system calls, which meant that no ZeroMQ call would ever return EINTR if a signal was received during its operation. This caused problems with loss of signals such as SIGINT (Ctrl-C handling), especially for language runtimes. In 2.1, any blocking ZeroMQ call such as zmq_recv[3] will return EINTR if it is interrupted by a signal."

From here http://www.zeromq.org/docs:2-1-upgrade. If anybody knows how to wrap my blocking calls such to handle EINTR then let me know.

EDIT: ok that's not the problem, that update is old. The problem still persist, and didn't existed before.

[ramiel]

Same here. Any idea?

[kevinoid]

I'm experiencing this issue as well. One easy way to reproduce the issue is to run node with the --prof option, which will cause SIGPROF to trigger the above error.

The way the error is propagated (through events rather than a callback) makes it difficult to handle the error in user code. It would be great if zeromq.node could either retry automatically or propagate the error in a way that user code can deal with the issue without a lot of contortions (or, if there is such a way already, to document it somewhere).

[aahoughton]

Jumping in. We're seeing this in production on relatively-highly-loaded boxes, a few times a day. We're using zmq 2.6.11, since it's what's stable in ubuntu LTS -- anyone know if newer versions of ZMQ meaningfully change the situations where an EINTR will end up in our code?

It seems like wrapping the send / receive in a domain (and adding the sockets to the domain) allows us to successfully catch 99% of the issues here, but we end up needing to disconnect / reconnect when that occurs. I'd love to hear if anyone else is seeing these, and how they worked around them.

[ronkorving]

This may just be due to funky timing, but this commit just landed into Node. I wonder if it could have something to do with this:
nodejs/node-v0.x-archive@c61b0e9

[DayBr3ak]

I tried to use the non stable version of node to check what ronkorving pointed out, but Zmq doesn't want to install with a "pre" version of node.
Can we have more information with this error, or how to work around it , it's just spawning randomly when I use my script.

[kkoopa]

Installing works perfectly fine. You just need to specify the nodeddir argument to npm, like the message says. Oh, right. It still won't build due to the v8 upgrades in node, so that's no help.

[hurricaneLTG]

Also seeing this issue. Is there any fix for the underlying issue, or is the only thing to do use domains to catch the exception?

[jiangzhuo]

Have zeromq.node already handled EINTR?

[ronkorving]

No, there is #340, but that was sort of abandoned :(