Re: Re: Errno::ENOMEM (but now with no reason)

[Eric Wong <normalperson@yhbt.net>]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Domingo, 10 de Enero de 2010, Iñaki Baz Castillo escribió:
> > El Domingo, 10 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > Hi, sometimes hen I change the name of the queue I get this error:
> > >
> > >   Cannot allocate memory - mq_open (Errno::ENOMEM)
> > >
> > > It would make sense if I haven't unlinked previous mqueues but I did it.
> > > In fact I mount /tmp/mqueue to display the existing mqueues and I can't
> > > see the previous one (as I deleted it with "POSIX_MQ.unlink(name)".
> > >
> > > More data:
> > > - The user running the command has "ulimit -q => 819200".
> > > - Queues default values (prox/sys/fs/mqueue) are:
> > >   - queues_max = 256
> > >   - msgsize_max = 8192
> > >   - msg_max = 50
> > >
> > > So 50x8192 = 409600 < 819200.
> > >
> > > Even more annoying: Being root I set "ulimit -q unlimited" and cannot
> > >  create the queue (being /tmp/mqueue empty, for sure I unlinked the queue
> > >  previously). But I become a normal user "ibc" (the user who created the
> > >  first queue) and I *can* create the mqueue!!
> > >
> > > These days I've detected it randonly and I'm very confused. Do I miss
> > > something?
> > 
> > Hummm, I ""think"" (not 100% sure yet) that it occurs always that I delete
> >  and try to create again a mqueue that was being used by other process (for
> >  writting). But why Errno::ENOMEM?
> 
> In fact, let's say process A is readin in /mq and B is writting there.
> I delete /mq (with POSIX_MQ.unlink or by deleting /mnt/mqueue/mq) and A still 
> can write and B still reads what A writes.

Hi Iñaki,

mq_unlink(3) and the normal unlink(2) system calls are very similar.  if
another process has the queue open, the queue stays alive until the last
process with the queue open closes it.  So what you're seeing is
expected behavior (see the mq_unlink(3) manpage or the POSIX_MQ#unlink
RDoc).

Continuing to use an open but unlinked file is common in Unix
applications.  This naturally extends to message queues as well.

> So IMHO it's not a memory allocation problem (it didn't make sense it to be) 
> but other kind of problem (trying to create a queue that still is in use even 
> if it was "theorically" deleted). Could it be detected?

Actually, it is a memory allocation problem.  "ulimit -q" is for the
user and all processes the they own.  On Linux, the getrlimit(2) manpage
(under RLIMIT_MSGQUEUE) documents this behavior.

-- 
Eric Wong