zeromq.node icon indicating copy to clipboard operation
zeromq.node copied to clipboard

Interrupted System Call

Open Darkie opened this issue 12 years ago • 10 comments

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 avatar Jan 08 '13 12:01 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.

Darkie avatar Jan 09 '13 10:01 Darkie

Same here. Any idea?

ramiel avatar Apr 23 '13 09:04 ramiel

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).

kevinoid avatar Aug 05 '13 00:08 kevinoid

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.

aahoughton avatar Apr 11 '14 16:04 aahoughton

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: https://github.com/joyent/node/commit/c61b0e9cbc748c5e90fc5e25e4fb490b4104cae3

ronkorving avatar Apr 14 '14 06:04 ronkorving

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.

DayBr3ak avatar Apr 17 '14 20:04 DayBr3ak

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.

kkoopa avatar Apr 18 '14 12:04 kkoopa

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?

hurricaneLTG avatar Jan 20 '15 20:01 hurricaneLTG

Have zeromq.node already handled EINTR?

jiangzhuo avatar Jan 21 '15 18:01 jiangzhuo

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

ronkorving avatar Jan 22 '15 02:01 ronkorving