How to trap USR2 for custom ussage ?

How to trap USR2 for custom ussage ?

[Iñaki Baz Castillo]

Hi, I've modified bin/unicorn to start a DRb server before last lines:

  MyApp::DRbServer.start(Process.pid)
  Unicorn::Launcher.daemonize! if daemonize
  Unicorn.run(app, options)

DRb server listens in port 5555. When I send a USR2 signal to unicorn master 
process I get an error because DRb is started again so:

  /usr/local/lib/ruby1.9/1.9.1/drb/drb.rb:861:in `initialize': Address already
  in use - bind(2) (Errno::EADDRINUSE)

The only solution I can imagine is to trap USR2 signal:

  MyApp::DRbServer.start(Process.pid)
  trap("USR2") { ::DRb.stop_service }
  Unicorn::Launcher.daemonize! if daemonize
  Unicorn.run(app, options)

Unfortunatelly it doesn't work because Unicorn overrides the 'trap' call so I 
don't get the USR2 signal.


Is there any way to achive this?
I could imagine a new config option "on_usr2" (or "before_reexec") so the 
passsed block would be executed upon receipt of USR2 (before the real "reexec" 
method).

Does it make sense?

Thanks a lot.

-- 
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: How to trap USR2 for custom ussage ?

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I've modified bin/unicorn to start a DRb server before last lines:
> 
>   MyApp::DRbServer.start(Process.pid)
>   Unicorn::Launcher.daemonize! if daemonize
>   Unicorn.run(app, options)
> 
> DRb server listens in port 5555. When I send a USR2 signal to unicorn master 
> process I get an error because DRb is started again so:
> 
>   /usr/local/lib/ruby1.9/1.9.1/drb/drb.rb:861:in `initialize': Address already
>   in use - bind(2) (Errno::EADDRINUSE)

First off I really don't think you need to be using DRb for this or
(generally) sticking things into the master process that don't belong
there.

> Is there any way to achive this?
> I could imagine a new config option "on_usr2" (or "before_reexec") so the 
> passsed block would be executed upon receipt of USR2 (before the real "reexec" 
> method).
> 
> Does it make sense?

There's already a similar before_exec hook documented in
http://unicorn.bogomips.org/Unicorn/Configurator.html
But it is called after forking, so the listener will be shared.

But again, you don't need to use DRb for this.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: How to trap USR2 for custom ussage ?

[Iñaki Baz Castillo]

El Miércoles, 23 de Diciembre de 2009, Eric Wong escribió:

> First off I really don't think you need to be using DRb for this or
> (generally) sticking things into the master process that don't belong
> there.

The problem is: how to start a server (which binds in a TCP port) in just one 
worker? humm, would the following make sense?:

  after_fork do |server, worker|
    # Start DRb server just in worker[0]
    if worker.nr == 0
      ... start DRb server ...
    end
  end

But it would also fail upon receipt of USR2 as there would be two instances of 
the DRb server trying to bind on same port...


> > Is there any way to achive this?
> > I could imagine a new config option "on_usr2" (or "before_reexec") so the
> > passsed block would be executed upon receipt of USR2 (before the real
> > "reexec" method).
> >
> > Does it make sense?
> 
> There's already a similar before_exec hook documented in
> http://unicorn.bogomips.org/Unicorn/Configurator.html
> But it is called after forking, so the listener will be shared.

Hummm, perhaps I could use the above code plus:

  before_exec do |server|
    .... stop DRb server ...
  end

In this way the DRb server is stopped before exec and started in the new 
worker[0].
Just a problem, how to access to existing/old worker[0] from "before_exec" in 
order to stop the DRb server?


 
> But again, you don't need to use DRb for this.

As I've said in other thread I want DRb to get some info related to the 
application. A DRb client console could be used to check application 
database(s) connection and so.
What would you suggest for this rather than DRb server?

 
Again thanks a lot for your help.


-- 
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: How to trap USR2 for custom ussage ?

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Miércoles, 23 de Diciembre de 2009, Eric Wong escribió:
> > But again, you don't need to use DRb for this.
> 
> As I've said in other thread I want DRb to get some info related to the 
> application. A DRb client console could be used to check application 
> database(s) connection and so.
> What would you suggest for this rather than DRb server?

As I said before, write an endpoint in your HTTP application that
calls and displays all the needed info you need.  Something that
hits the database(s) and/or whatever else you're using.

There's no need to introduce another socket protocol into that process.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: How to trap USR2 for custom ussage ?

[Iñaki Baz Castillo]

El Jueves, 24 de Diciembre de 2009, Eric Wong escribió:

> > As I've said in other thread I want DRb to get some info related to the
> > application. A DRb client console could be used to check application
> > database(s) connection and so.
> > What would you suggest for this rather than DRb server?
> 
> As I said before, write an endpoint in your HTTP application that
> calls and displays all the needed info you need.  Something that
> hits the database(s) and/or whatever else you're using.

Can Rack/Unicorn behave different depending on the request received port?
This is: I could run Unicorn in port 80 for clients access and port 5000 for 
admin access (status and so).
However I couldn't find in Rack specification, neither in Unicorn, a way to 
inspect the port in which the request was received by the http server. Is it 
possible?


> There's no need to introduce another socket protocol into that process.

Yes, I'm realizing that openging another socet protocol gets in conflict with 
Unicorn signals usage. For example USR2 + QUIT is really great as it allows to 
reload/restart a server and go back to the previos running instance if the new 
one fails in some way.
So I'll use HTTP instead of DRb protocol to display the server status.

Thanks a lot again.
 


-- 
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: How to trap USR2 for custom ussage ?

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Jueves, 24 de Diciembre de 2009, Eric Wong escribió:
> > > As I've said in other thread I want DRb to get some info related to the
> > > application. A DRb client console could be used to check application
> > > database(s) connection and so.
> > > What would you suggest for this rather than DRb server?
> > 
> > As I said before, write an endpoint in your HTTP application that
> > calls and displays all the needed info you need.  Something that
> > hits the database(s) and/or whatever else you're using.
> 
> Can Rack/Unicorn behave different depending on the request received port?
> This is: I could run Unicorn in port 80 for clients access and port 5000 for 
> admin access (status and so).
> However I couldn't find in Rack specification, neither in Unicorn, a way to 
> inspect the port in which the request was received by the http server. Is it 
> possible?

Unicorn should always be running behind nginx if you're dealing with
untrusted clients, so you should just have nginx protecting the admin
endpoints.  The SERVER_PORT Rack environment variable is
available, but not considered trustable since it reads the value
of the Host: HTTP header.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying