Iñaki Baz Castillo <[email protected]> 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 _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
