I run a testing server for software that depends on the massive usage of mqueues (POSIX messages queues). I increased limits to a reasonable level and got it working a long time ago. However, the number of tests (and their mqueues) keeps rising and the tests are starting to fail at creating new mqueues, although the limits don’t seem to be exhausted.

$ cat /proc/sys/fs/mqueue/queues_max    # maximum mqueue count
$ sudo mount -t mqueue none /mnt
$ ls -1 /mnt | wc -l                    # current mqueue count
$ ulimit -q                             # maximum bytes in mqueues
$ du -s /mnt                            # current mqueues size
0       /mnt

After a failing call to mq_open(), errno is set to 24 which means (according to /usr/include/asm-generic/errno-base.h):

#define EMFILE          24      /* Too many open files */

Therefore I checked the limit for open files but it seems to be not exhausted, too.

$ ulimit -n                             # file descriptors limit
$ lsof -u $(whoami) | wc -l             # currently open files

Are these checks correct? Is there anything more I should check?

I have looked at How to check ulimit usage but the usage checks seem to be specific to particular limits and mqueues are not mentioned there.

Since the behavior of mqueues has been changing over time due to bugs, my kernel version is 4.1.13-rt15+. I built the kernel myself using the appropriate real-time patch with no further modifications. I have not switched the kernel recently (when the problem started to appear).

  • Why the need for real time patches in non-desktop? Jan 3, 2018 at 10:37
  • @RuiFRibeiro The safety-related software I test. AFAIK the real-time patch is intended for industrial usage, not a desktop. See the Linus Torvalds quote on rt.wiki.kernel.org/index.php/Main_Page.
    – Melebius
    Jan 3, 2018 at 10:47
  • Yes, there is also the industrial usage/iOT side...specific requirements indeed. Jan 3, 2018 at 11:03


You must log in to answer this question.

Browse other questions tagged .