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

Pieter Hintjens ph at imatix.com
Thu May 21 17:50:00 CEST 2015


Please retest with ZeroMQ 4.x as this behavior was changed to not
assert when running out of sockets. There's a default limit on the
sockets per context of 1024, which is why you get a graceful error at
that level. A single ZeroMQ socket uses two system file handles.

On Thu, May 21, 2015 at 5:16 PM, Michael Devereaux
<Michael.Devereaux at quantum.com> wrote:
> 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.
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list