mongrel unicorn - Jan 2010 - stderr_path doesn't work at the moment of being called

Hi, in unicorn.conf.rb I want to log a welcome message (current datetime 
basically) to the error log, so I do:

  if Process.ppid == 1 || Process.getpgrp != $$
    stderr_path "/tmp/error.log"
    $stderr.puts "#{Time.now} Starting..."

Unfortunatelly the message is displayed in the terminal rather than the file.

However with the following hacks the message is displayed in the file:

a)
  stderr_path "/tmp/error.log"
  $stderr.reopen "/tmp/error.log"
  $stderr.puts "#{Time.now} Starting..."

b)
  stderr_path "/tmp/error.log"
  File.open("/tmp/error.log", ''ab'') { |fp|
$stderr.reopen(fp) }
  $stderr.puts "#{Time.now} Starting..."
  

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?

Thanks a lot.

-- 
I?aki Baz Castillo <ibc at aliax.net>

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?


-- 
I?aki Baz Castillo <ibc at aliax.net>

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

El Martes, 5 de Enero de 2010, Eric Wong escribi?:
> 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.
Ok, it makes sense :)
Thanks. 


-- 
I?aki Baz Castillo <ibc at aliax.net>