stderr_path doesn't work at the moment of being called

Iñaki Baz Castillo ibc at
Tue Jan 5 17:50:24 EST 2010

El Martes, 5 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc at> 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 :)

Iñaki Baz Castillo <ibc at>

More information about the mongrel-unicorn mailing list