"mode" and varios processes sharing the same queue for writting

"mode" and varios processes sharing the same queue for writting

[Iñaki Baz Castillo]

Hi, I'll have an external process (running as root) which creates a posix_mq 
queue just for read-only. As it runs as root I can set a longer "maxmsg" 
value.

Then I've other processes (Unicor workers) running as non privileged users and 
must write in that queue.

So in the external process I do:

  File.umask(0000)
  MQ = POSIX_MQ.new "/mq", IO::RDONLY | IO::CREAT, 00002

"mode" = 00002 which means "others have write permission" (in combination with 
the modified umask, of course, if not it doesn't work).

Is it the correct approach?


And the other question: Being posix_mq process/thread safe, does it mean that 
I could open the queue writter in the master process so it could be safely 
shared by all the workers? or shall I open the queue writter for each worker?


PS: Thanks a lot for this project, it's exactly what I needed (much better 
than using DRb o UNIXsockets) :)

PPS: Is there any other cool project you are involved in? :)


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

Re: "mode" and varios processes sharing the same queue for writting

[Iñaki Baz Castillo]

El Viernes, 8 de Enero de 2010, Iñaki Baz Castillo escribió:
> Then I've other processes (Unicor workers) running as non privileged users
>  and  must write in that queue.
> 
> So in the external process I do:
> 
>   File.umask(0000)
>   MQ = POSIX_MQ.new "/mq", IO::RDONLY | IO::CREAT, 00002
> 
> "mode" = 00002 which means "others have write permission" (in combination
>  with  the modified umask, of course, if not it doesn't work).

Well, auto-fix:

Setting such "mode" makes no sense as the above umask already allows any 
operation from "others".
So I should change the effective group of the process creating the queue byy 
setting the same group as the readers will use. 


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

Re: "mode" and varios processes sharing the same queue for writting [SOLVED]

[Iñaki Baz Castillo]

El Viernes, 8 de Enero de 2010, Iñaki Baz Castillo escribió:
> Hi, I'll have an external process (running as root) which creates a
>  posix_mq queue just for read-only. As it runs as root I can set a longer
>  "maxmsg" value.
> 
> Then I've other processes (Unicor workers) running as non privileged users
>  and must write in that queue.
> 
> So in the external process I do:
> 
>   File.umask(0000)
>   MQ = POSIX_MQ.new "/mq", IO::RDONLY | IO::CREAT, 00002
> 
> "mode" = 00002 which means "others have write permission" (in combination
>  with the modified umask, of course, if not it doesn't work).
> 
> Is it the correct approach?

The already working solution:

----------------------------------
group_name   = ARGV[0]

# Change the effective group (just if we are root).
if Process.euid == 0 and group_name
  gid = Etc.getgrnam(group_name).gid
  puts "setting effective group to '#{group_name}' (gid #{gid})..."
  Process::GID.change_privilege(gid)
end

# Change umask to 0047 so the group has write permissions for the posix_mq.
File.umask(0047)  # => When creating a file permissions are:  -rw--w----

MQ = POSIX_MQ.new "/my_mq", IO::RDONLY | IO::CREAT, 00620
--------------------------------

In this way a user whose primary group is "group_name" will have write access 
(but no read access) to the mqueue. :)



> And the other question: Being posix_mq process/thread safe, does it mean
>  that I could open the queue writter in the master process so it could be
>  safely shared by all the workers? or shall I open the queue writter for
>  each worker?

After some testing I would say that it's totally safe (it works for me by 
creating the mqueue writter in the master process).



Best regards.


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

Re: "mode" and varios processes sharing the same queue for writting

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I'll have an external process (running as root) which creates a posix_mq 
> queue just for read-only. As it runs as root I can set a longer "maxmsg" 
> value.
> 
> Then I've other processes (Unicor workers) running as non privileged users and 
> must write in that queue.
> 
> So in the external process I do:
> 
>   File.umask(0000)
>   MQ = POSIX_MQ.new "/mq", IO::RDONLY | IO::CREAT, 00002
> 
> "mode" = 00002 which means "others have write permission" (in combination with 
> the modified umask, of course, if not it doesn't work).
> 
> Is it the correct approach?
> 
> 
> And the other question: Being posix_mq process/thread safe, does it mean that 
> I could open the queue writter in the master process so it could be safely 
> shared by all the workers? or shall I open the queue writter for each worker?

Hi Iñaki,

I'm glad you were able to answer your own questions while I was away.
Yes the mode argument is handled exactly like how the open(2) syscall
works (and File.open(), too).

> PS: Thanks a lot for this project, it's exactly what I needed (much better 
> than using DRb o UNIXsockets) :)

No problem, I'm glad this POSIX feature is getting more exposure :)

> PPS: Is there any other cool project you are involved in? :)

"cool" is up for the users to decide :)  I strongly prefer people
evaluate/use projects without taking the reputation (good or bad)
of the author(s) into account.

Of course I'll announce any worthwhile Ruby projects I release on
ruby-talk/RAA and use language/community-specific mailing lists
and/or Freshmeat.

-- 
Eric Wong

Re: "mode" and varios processes sharing the same queue for writting

[Iñaki Baz Castillo]

El Viernes, 8 de Enero de 2010, Eric Wong escribió:

> Yes the mode argument is handled exactly like how the open(2) syscall
> works (and File.open(), too).

AFAIK it's not possible to open a queue and change just the maxmsg parameter. 
Instead all the "attr" fields must be set again.
And also there is no way to know the system default values (those in 
/proc/sys/fs/mqueue/*). The only way is by opening (creating in fact) a new 
mqueue and inspecting its values.

 
> > PS: Thanks a lot for this project, it's exactly what I needed (much
> > better than using DRb o UNIXsockets) :)
> 
> No problem, I'm glad this POSIX feature is getting more exposure :)

It's really great for me. It works really well by having different writers 
processes and different reader processes sharing the same mqueue (load 
balancing out of the box) :)



Thanks a lot again.

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

Re: "mode" and varios processes sharing the same queue for writting

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Viernes, 8 de Enero de 2010, Eric Wong escribió:
> 
> > Yes the mode argument is handled exactly like how the open(2) syscall
> > works (and File.open(), too).
> 
> AFAIK it's not possible to open a queue and change just the maxmsg parameter. 
> Instead all the "attr" fields must be set again.
> And also there is no way to know the system default values (those in 
> /proc/sys/fs/mqueue/*). The only way is by opening (creating in fact) a new 
> mqueue and inspecting its values.

Correct.  POSIX message queues were designed for real-time systems and
one way to help ensure deterministic real-time behavior is to keep
memory preallocated for them.  In-kernel memory is also unswappable, too
(at least under Linux), so you'll never have to wait on disk access.

> > > PS: Thanks a lot for this project, it's exactly what I needed (much
> > > better than using DRb o UNIXsockets) :)
> > 
> > No problem, I'm glad this POSIX feature is getting more exposure :)
> 
> It's really great for me. It works really well by having different writers 
> processes and different reader processes sharing the same mqueue (load 
> balancing out of the box) :)

Good to know, I've yet to test them under high load myself :)

-- 
Eric Wong

Re: "mode" and varios processes sharing the same queue for writting

[Iñaki Baz Castillo]

El Sábado, 9 de Enero de 2010, Eric Wong escribió:
> > It's really great for me. It works really well by having different
> > writers  processes and different reader processes sharing the same mqueue
> > (load balancing out of the box) :)
> 
> Good to know, I've yet to test them under high load myself :)

I've done some benchmarks as follows:

- Unicorn with 8 workers and each worker also writting in a shared mq 
(maxmsg=50) for each HTTP request (non-blocking writting).

- Other 8 processes acting as mq readers in parallel (blocking reading). For 
each message the reader simulates some work by sleeping during 0.002 seconds.

- Apache ab test with 5000 requests and concurrency 10.

With these settings there are no errors (the queue is always available). By 
incrementing a bit the sleeping time then some errors occur since the queue 
buffer gets full sometimes (totally expected of course).

But the more great thing is the fact that each mq reader process receives a 
similar ammount of messages, so the kernel gives us a perfect load balancing 
system :)



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