El Martes, 5 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <i...@aliax.net> wrote:
> > El Martes, 5 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > The second workaround is exactly what Unicorn does when calling to
> > > "stderr_path" ("redirect_io" method). So, why doesn't work for me
> > > without the hacks? do I miss something?
> >
> > By running 'exec "ls -l /proc/$$/fd"' after 'stderr_path' I've realized
> > that the stderr is still pointing to /dev/pts/N. Perhaps the method is
> > called later and now it's just "eval"-ulated?
>
> The value is stored and then set later. I avoid changing internal
> configuration variables during evaluation time for several reasons:
>
> 1. A Unicorn config file is typically the last thing configured for an
> application, when a user is testing their configuration it's easier
> to see the error message in the console if it's in the Unicorn
> config file
>
> 2. HUP-ing a with a bad config file should not leave the server in an
> unknown state. There are still some things that bind immediately
> (working_directory, all of Rainbows!) for now, but for the most
> part it should be possible to recover on bad HUPs.
>
> 3. "working_directory" needs to be factored in for non-absolute paths.
> I prefer to work with absolute paths, but some people like
> non-absolute ones for various reasons. So we always ensure
> stderr_path is set after "working_directory" is called.
Ok, it makes sense :)
Thanks.
--
Iñaki Baz Castillo <i...@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
