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

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

El Miércoles, 23 de Diciembre de 2009, Eric Wong escribió:
> > Usually if a worker (all the workers) fail to start at the moment of
> > running  it, it obviously means that there is some error in the
> > application with prevents it to run. It could be great if Unicorn could
> > detect it.
> 
> I'm generally hesitant to introduce code/features/bloat that aren't
> helpful to people who properly test configurations before deploying :)
> 
> Adding this code doesn't solve problems.  Either way the site can become
> inaccessible/unusable and problems are noticeable very quickly.

Ok, I should explain better why I need this feature:

I'm not coding a HTTP app on top of Unicorn to host in a server. Instead I'm 
building a XCAP server (RFC 4825) using Rack and Unicorn. I'll also publish a 
Ruby gem containing all the server (Unicorn + Rack application).

So, any user could install the gem, set the database(s), fill the 
configuration file and star the server in background by running the provided 
init script ("/etc/init.d/xcapserver start") which runs the server daemonized.

Imagine that the user wrote a typo, i.e:

  after_fork do |server, worker|
    # Note the space typo:
    worker.u ser("www-data", "www-data") if Process.euid == 0
  end

Then the init script would return 0 (success) but the server wouldn't work. 
The user would check "ps aux | grep xcapserver" and would see the xcapserver 
running. It would be complex to understand why the server it's failing.

So it would be great the following:

- The user start the init script (which calls "unicorn -D ...") with a 
hypotethical new option ("--no-error-time 2").

- The command "unicorn -D" remains in foreground for 2 seconds before master 
process going to background.

- Unicorn fails to create the workers at the moment (so within 2 seconds).

- Instead of re-spawning them, the command (still in foreground) exits with 
return code 1 (error).




But there is other case which is much wrose IMHO. Imagine the user writes a 
space typo:

    stde rr_path "/var/log/xcapserver.err.log"

or imagine it uses a path that doesn't exist (/var/log/xcapserver/ doesn't 
exist):

    stderr_path "/var/log/xcapserver/err.log"

In both cases "unicorn -D" returns 0 but the server is not running (no unicorn 
process running). So, why did it return 0? It's not an error when creating the 
workers, but when running also the master process. IMHO in this case Unicorn 
should return non zero (even if it called with "-D").


I'm playing right now with unicorn/launcher.rb (daemonize! method)but I get 
nothing. Unfortunatelly I think that the usage of fork makes very difficult 
the main command to behave as I desire (exit status).

If you could give me some tips I'd try to implement it.

Reall thanks a lot again and 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