[zeromq-dev] question on zmq_socket failure returning null socket, zmq lib assertion with core dump, and Linux hard and soft limits

[Michael Devereaux]

We've seen that on a  RedHat Linux OS, where 'ulimit -Sn' and 'ulimit -Hn' return soft and hard limits of 1024 and 2048 respectively, that when zmq_socket is called repeatedly to open many sockets, the zmq lib will core dump with an assertion when opening the 508th ipc or tcp socket:
    Too many open files (signaler.cpp:230)
    Aborted (core dumped)

Changing the soft limit as root to 2048 changes the assertion/core dump to occur on socket # 1020.

As root, changing both soft and hard limits to 4096, or to 8192, causes, not the assertion with core dump, but a failure where zmq_socket returns NULL, with errno set to EMFILE, notably not just for ipc and tcp, but also for inproc sockets.  Importantly this occurs on socket # 1024.


1.       Do you understand why we would get the signaler.cpp:230 mailbox assertion with core dump for lower values for the soft and hard limits, and a zmq_socket NULL error for higher values for the soft and hard limits?  We cannot allow our app processes to core dump, so the higher soft and hard limits will be necessary and sufficient to avoid that; but I am interested in understanding why, for lower soft and hard limits, the assertion even occurs, rather than zmq_socket simply returning NULL.

2.       More importantly:  When the larger soft and hard limits of 4092 or 8192 are in place (and no other file descriptors are used by the process), why does zmq_socket fail and return NULL, with errno=EMFILE, at the much smaller value of 1024?  Are we doing something wrong?  Can we change anything, so that zmq will honor the larger soft and hard limits?  Hopefully meaning that, for example, when we set the soft and hard limits as root to 8192, for example, that zmq_socket will not fail and return NULL until the number of open sockets in the process reaches a value much closer to 8192?

3.       Do you understand/can you explain why, when the soft and hard limits on file descriptors are set to 2048 or higher, that we will fail at the 1024th ***INPROC*** socket as well, returning NULL for zmq_socket on the 1024th zmq_socket call?  Again, are we doing something wrong?  Can we change anything, such that the higher soft and hard limit values for file descriptors are honored for INPROC instead of the lower zmq 1024 limit?


We currently use zeromq version 3.2.3-7 on RedHat 6 where observing this behavior.

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150521/0604bffc/attachment.htm>