Your message dated Mon, 15 Jun 2015 18:45:08 +0200
with message-id <20150615164508.gb3...@aurel32.net>
and subject line Re: Bug#787807: libc6: mq_open unexpectedly fails with errno 24
has caused the Debian Bug report #787807,
regarding libc6: mq_open unexpectedly fails with errno 24
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
787807: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787807
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Severity: normal
Dear Maintainer,
I have an application that uses Posix message queues since a while.
Today I realized that mq_open fails with errno 24 where it worked before.
(errno 24: Too many open files)
Here is a short C file to reproduce the problem.
Before you start it, you have to increase msg_max system default:
sysctl -w fs.mqueue.msg_max=1000
Now (as normal user) execute the following code:
#include <stdio.h>
#include <mqueue.h>
#include <errno.h>
void main(void) {
struct mq_attr attr={.mq_maxmsg=900,.mq_msgsize=1020};
int rc=mq_open("/xxx",O_CREAT | O_RDONLY, 0600, &attr);
printf("rc=%d errno=%d\n",rc,errno);
}
It returns errno 24. Using a value of 800 for .mq_maxmsg returns success.
Compile with gcc x.c -o x -lrt.
The system settings should allow the above values without problem:
$ ls /proc/sys/fs/mqueue/|more
msg_default
msg_max
msgsize_default
msgsize_max
queues_max
$ cat /proc/sys/fs/mqueue/*
10
1000
8192
8192
256
Regards, Tim
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 2015-06-15 17:25, Tim Ruehsen wrote:
> On Monday 15 June 2015 15:21:52 Aurelien Jarno wrote:
> > > > I made some tests on Debian VMs, that I have flying around.
> > > >
> > > > Debian SID with 4.0 (amd64): problem as described above
> > > > Debian SID with 3.16 (amd64): same problem
> > > > Debian Wheezy with 3.2.0 (amd64): same problem
> > > > Debian Wheezy with 3.2.0 (i386): Works as expected (up to maxmsg=1000,
> > > > with
> > > > maxmsg=1001 I get errno=22 (Invalid argument) - that's fine for me, but
> > > > is not what the man page says for this case.
>
> Ok, forget about the man pages. I was just puzzled by multiple entries per
> error number.
>
> > > > Looks like amd64 architecture has the problem since a while.
> > >
> > > I don't really know what is the problem, but a strace shows that the
> > > glibc just returns the errno from the kernel.
> >
> > What does "ulimit -q" returns on your system? It seems to be 819200 by
> > default, which is why the kernel refuses to create the message queue.
>
> Yes, it is 819200 on i386 (Wheezy) and on amd64 (SID) here.
>
> > Here increasing the value allows the msg queue to be created
> > successfully. The way to compute the limit is described in the
> > getrlimit(2) manpage. Note that the value includes size of structures,
> > which are likely to be different on i386 and amd64, and has changed
> > starting with kernel 3.5. It's therefore likely that by using an
> > amd64 machine and a recent kernel, you crossed the 819200 limit.
>
> Woooh, thanks for that hint ! Wouldn't have thought about this for a while...
>
> BTW, using /etc/security/limits.conf to increase that value (tried hard,
> soft,
> - for * and for the user) does not increase the users ulimit value (nor
> permits him to increase it via ulimit). But that is another story... did not
> test a reboot yet.
For what I have found you need both hard and soft limits in this file.
And you don't need to reboot, but just login again.
> Many thanks for your help. I guess you can close this bug.
Ok, doing so with this mail.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: Digital signature
--- End Message ---
