stderr_path doesn't work at the moment of being called

Eric Wong normalperson at yhbt.net
Tue Jan 5 16:47:08 EST 2010


Iñaki Baz Castillo <ibc at 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.

-- 
Eric Wong


More information about the mongrel-unicorn mailing list