Errno::ENOMEM (but now with no reason)

Errno::ENOMEM (but now with no reason)

[Iñaki Baz Castillo]

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?

Regards.




  



-- 
Iñaki Baz Castillo <ibc@aliax.net>

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

[Iñaki Baz Castillo]

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?


-- 
Iñaki Baz Castillo <ibc@aliax.net>

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

[Iñaki Baz Castillo]

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.

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?


-- 
Iñaki Baz Castillo <ibc@aliax.net>

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

[Eric Wong]

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

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

[Iñaki Baz Castillo]

El Domingo, 10 de Enero de 2010, Eric Wong escribió:
> > 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.

Yes, I expected it.


> > 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.

So, the problem I was experimenting was because I tried to create a new mqueue 
when the previous one still existed (even if it was unlinked).
Ok, thanks a lot for your explanation.


-- 
Iñaki Baz Castillo <ibc@aliax.net>