How to reopen error log for rotation ?

[coxx]

What is the right way to reopen log file (--error-log) for graceful rotation ?

[anton-nikolaev]

Would like to know this too. Need a signal number to send, or some run flag, or something else. And this function (log file reopen) should not delay requests processing and i suppose should not force starman to reread psgi app.

[miyagawa]

Just since you guys were asking "how" - the answer is that it's not supported as of currently.

[coxx]

Thanks Tatsuhiko! "Not supported" is enough for "how to".

[benrifkah]

I'm looking at implementing a workaround to do this using the pluggable logging facility of Starman::Server's base class Net::Server in combination with Log::Log4perl's ability to re-open log files via the Log::Log4perl::Appender::File recreate_check_signal option. However, this requires passing command line parameters that Net::Server can access and Starman::Server->run doesn't pass them on. (starman passes unknown parameters to Plack::Runner and they get stored as key value pairs in $self->{options} but they don't make it to Net::Server which expects them in $self->{server}.)

I put a rather broad hack in that works for me but my setup doesn't really exercise all of the command line parameters so I'm not sure if the hack breaks anything else. I tried to run it against the test suite using "cpanm --look starman" but I don't know my way around the build dir structure well enough to get anything done and there weren't any instructions.

Here is the diff if you're interested:

*** lib/Starman/Server.pm       2013-04-06 22:04:57.000000000 -0700
--- lib/Starman/Server.new.pm   2013-04-17 11:14:23.121528622 -0700
***************
*** 66,69 ****
--- 67,74 ----

      $self->SUPER::run(
+         # Pass all raw command line options to our parent Which expects them
+         # here. Any that need to be modified by our option parsing get
+         # clobbered below
+         %$options,
          port                       => $port,
          host                       => $host,

[karenetheridge]

Could we not simply change the logging so it closes/reopens the filehandle on every write? This file doesn't usually get written to that often, so it wouldn't be inefficient.

[benrifkah]

@karenetheridge that would be one approach to adding this functionality. So would just re-opening the handle on HUP. But, Net::Server doesn't offer an API for directly affecting the filehandle. The filehandle itself appears to be intended as private so I am hesitant to add code that depends upon it's implementation. One alternative would be to override the methods that access the filehandle, however those are big methods and it seemed like that couldn't be done easily without a lot of copy pasta. Another alternative would be to submit a patch to Net::Server that exposed the filehandle for fiddling.

I opted for the code I shared above because it's changes far fewer lines of code, uses the parent's exposed API and adds exposure to other parts of the parent's API. The downside is that the pluggable logging does require more configuration up-front.

[lestrrat]

@benrifkah I know you want to use Log4perl et al, but just as a FYI, we use this setup at $work:

use strict;
use Plack::Builder;
use File::RotateLogs;

my $roratelogs = File::RotateLogs->new(
    logfile         => "/path/to/logfile.%Y%m%d%H",
    linkname        => "/path/to/logfile",  # symlink pointing to newest one
    rotationtime    => 7200, # when to rotate logs (short, because we get a LOT of hits)
    maxage          => 86400 * 14, # when to purge old olgs
);

builder {
     enable 'AccessLog', logger => sub { $rotatelogs->print(@_) };
     $app;
};

[benrifkah]

@lestrrat that is a great way to ensure that the ACCESS log gets rotated. It is similar to what we're doing with Log4perl. However, I think you'll find that it doesn't work for the ERROR log which is what this thread is about. Since the error log filehandle is owned by Net::Server which isn't aware of Plack::Builder it would take breaking some API boundaries to make it configurable via middleware.

[lestrrat]

@benrifkah Oh I see. My bad. Again, just FYI we don't worry about doing error log locations because we just print it to STDERR and let daemontools' multilog handle the log management.

[robrwo]

Actually, is this even needed? You can create a "Net::Server::Log::MyClass" class that handles the logging, and then for the error-log parameter pass "MyClass". It works.