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 at aliax.net>
I?aki Baz Castillo <ibc at 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
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 at aliax.net>
I?aki Baz Castillo <ibc at 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
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 at aliax.net>
I?aki Baz Castillo <ibc at 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