Reopening logs - why no relative paths?

Reopening logs - why no relative paths?

[Matthew Kocher]

We just spend a couple hours trying to figure out why sending a USR1
signal wasn't causing unicorn to reopen logs.  Looking at the source
reveals that only files opened with absolute paths are eligible for
rotation, the others are silently skipped.

We use the fairly standard practice of always logging to
log/unicorn.error.log and creating symlinks to where we'd like the
logs to live on individual hosts.  We'll change our configs for the
time being, but is there a reason to not reopen the relative paths?

Thanks,
Matthew
_______________________________________________
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: Reopening logs - why no relative paths?

[Eric Wong]

Matthew Kocher <mkocher@pivotallabs.com> wrote:
> We just spend a couple hours trying to figure out why sending a USR1
> signal wasn't causing unicorn to reopen logs.  Looking at the source
> reveals that only files opened with absolute paths are eligible for
> rotation, the others are silently skipped.
> 
> We use the fairly standard practice of always logging to
> log/unicorn.error.log and creating symlinks to where we'd like the
> logs to live on individual hosts.  We'll change our configs for the
> time being, but is there a reason to not reopen the relative paths?

It's ambiguous due to directory changes[1].  It may be easier now that
we have the "working_directory" directive now, but configuration changes
also change (or unset) the "working_directory" which adds to the
confusion.

We could try allowing it and see what happens, I suppose...


[1] - in my experience with writing daemons, directory changes make
      everything much harder all around.
-- 
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: Reopening logs - why no relative paths?

[Eric Wong]

Eric Wong <normalperson@yhbt.net> wrote:
> Matthew Kocher <mkocher@pivotallabs.com> wrote:
> > We just spend a couple hours trying to figure out why sending a USR1
> > signal wasn't causing unicorn to reopen logs.  Looking at the source
> > reveals that only files opened with absolute paths are eligible for
> > rotation, the others are silently skipped.
> > 
> > We use the fairly standard practice of always logging to
> > log/unicorn.error.log and creating symlinks to where we'd like the
> > logs to live on individual hosts.  We'll change our configs for the
> > time being, but is there a reason to not reopen the relative paths?
> 
> It's ambiguous due to directory changes[1].  It may be easier now that
> we have the "working_directory" directive now, but configuration changes
> also change (or unset) the "working_directory" which adds to the
> confusion.
> 
> We could try allowing it and see what happens, I suppose...

Just pushed this out, thinking about it more I don't think it'll have an
adverse effect on most installations out there...

>From 6647dcb3afa4c0b16c5fef5bfdf88292e6adf6ca Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 1 Apr 2011 16:09:03 -0700
Subject: [PATCH] util: allow relative paths to be rotated

Users keep both pieces if it's broken :)
---
 lib/unicorn/util.rb |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/lib/unicorn/util.rb b/lib/unicorn/util.rb
index 82329eb..cde2563 100644
--- a/lib/unicorn/util.rb
+++ b/lib/unicorn/util.rb
@@ -8,7 +8,6 @@ module Unicorn::Util
 
     ! fp.closed? &&
       fp.sync &&
-      fp.path[0] == ?/ &&
       (fp.fcntl(Fcntl::F_GETFL) & append_flags) == append_flags
     rescue IOError, Errno::EBADF
       false
@@ -25,10 +24,12 @@ module Unicorn::Util
   # using logrotate(8) (without copytruncate) or similar tools.
   # A +File+ object is considered for reopening if it is:
   #   1) opened with the O_APPEND and O_WRONLY flags
-  #   2) opened with an absolute path (starts with "/")
-  #   3) the current open file handle does not match its original open path
-  #   4) unbuffered (as far as userspace buffering goes, not O_SYNC)
+  #   2) the current open file handle does not match its original open path
+  #   3) unbuffered (as far as userspace buffering goes, not O_SYNC)
   # Returns the number of files reopened
+  #
+  # In Unicorn 3.5.x and earlier, files must be opened with an absolute
+  # path to be considered a log file.
   def self.reopen_logs
     to_reopen = []
     nr = 0
-- 
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