Re: "unicorn -D" always returns 0 "success" (even when failed to load)

["Iñaki Baz Castillo" <ibc@aliax.net>]

El Sábado, 26 de Diciembre de 2009, Eric Wong escribió:

> >   http://oversip.net/public/min_time_running.rb
> >
> > It contains a modification for bin/unicorn and a rewritten
> > lib/unicorn/launcher.rb.
> 
> Interesting, I could be tempted to accept this with a few changes...
> 
> Process.detach() spawns a background Thread.  Having running threads
> before forking won't fly with certain OS threading libraries (some
> versions of FreeBSD, I believe, check MRI Redmine for some open bugs).

Yes, but there is a problem:
Imagine I don't use Process.detach and the master process ends when loads the 
rack application (due to a typo or due to an error in unicorn conf file).
Then the master process would remain visible/alive but as zombie.
If so, when the controller process sends signal 0 to check the master process 
it will always receive 'true' (a zombie process is a process which can receive 
signals, it's does exist).

If I could check if the master process is zombie then I wouldn't need 
Process.detach, but I don't know how to check if a process is zombie, no way 
in:
  http://ruby-doc.org/core/classes/Process.html
  http://ruby-doc.org/core/classes/Process/Status.html

Any suggestion here?

 

> Use trap(Symbol), trap(Integer) is harder to read and has a likelyhood
> of being non-portable for certain signals.  Likewise with Process.kill
> (0 being the only exception, of course).

Sure, I'll change it.

 
> I would trap() in the parent before any forking, in case the
> sleep time is ever so low there's a race condition.

Ok.


> Probably no need to handle USR1, either, just let the parent die on its own,

Note that the parent sleeps for 'min_running_time' + 1 (to avoid exiting 
before receiving USR1 or USR2 from the controller process). But if the 
controller process sends USR1 then the parent can already exit without waiting 
one second more.
Well, this is not very interesting, but I think it's good in order to get a 
faster exit code (it's not a good idea that a daemon takes long time to start 
and return ans exit status).


> or alternatively, have the parent sleep forever in case something
> unforseen happens in the children...

But then the parent process doesn't end and continues in foreground. This is 
not valid for running as daemon. The parent process must exit with the 
appropriate status code after a few seconds to behave as any service running 
in background.


> > The code works for me for the two cases I explained in my previous mail.
> > Of course it's an optional feature (I've implemented it with "-M --min-
> > running-time SECONDS" in the options parser).
> 
> I believe the nginx grace period is hard-coded at 5 seconds, which should
> be enough.

Sorry, I don't know ngix. I need to use other reverse proxy (Pound) but let me 
open a new thread about it :)

Anyhow I don't understand what you mean with "nginx grace period". How does 
affect to Unicorn? Do you mean that, in case of implementing the above, 
Unicorn wouldn't need a --min-running-time option? (I expect it would be 
required since Unicorn is 100% independent of ngix)



Really thanks a lot. I'll do the changes you suggest and show you again (but 
still don't know how to avoid Process.detach for now...).



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