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. Many thanks for your help. I guess you can close this bug. Best Regards Tim
signature.asc
Description: This is a digitally signed message part.
