stderr_path doesn't work at the moment of being called

stderr_path doesn't work at the moment of being called

[Iñaki Baz Castillo]

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@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

Re: stderr_path doesn't work at the moment of being called

[Iñaki Baz Castillo]

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@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

Re: stderr_path doesn't work at the moment of being called

[Eric Wong]

Iñaki Baz Castillo <ibc@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
_______________________________________________
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

Re: stderr_path doesn't work at the moment of being called

[Iñaki Baz Castillo]

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