configuring logfile location

42 views
Skip to first unread message

Roger Crew

unread,
Jun 22, 2016, 9:12:54 PM6/22/16
to Mojolicious
So I want to have the location of the log file be configurable.
And either I'm missing something basic or this is surprisingly painful.
I saw this discussion:


and it looks like the end result/consensus was that log configuration should live in the config file with all of the other application options (... not sure how this squares with the statement that server configuration and application configuration need to be separate; then again this was a decision made 4 years ago and it looks like people were generally happy with it, so I'm not sure if you'd want to change it now anyway...)

If log configuration info is in the config file then the first thing we have to do is read it:

    $self->plugin('Config');

but then:

(1) depending on what mode we're in, that much MAY already emit a log message -- currently it does in 'debug' mode to say what config file it's reading, otherwise not, but that behavior could change, never mind that config files themselves are executable and could theoretically do anything (even if they really shouldn't)

(2) once a log message has been emitted, it's non-trivial to redirect the log.   Setting log->path to a new value works as long as nothing has been logged yet, but otherwise the handle is open and changing log->path does nothing.

As things currently stand, I'm having to do this:

    # redirect log if specified in config
    if (my $log_path = $self->config->{log_path}) {
my $log = $self->log;
say "Logging at $log_path";
$log->debug("Log redirected to $log_path") if $log->{path};

# capture and close prior handle if necessary
my $prev_handle = delete $log->{handle};
close $prev_handle
  if $prev_handle && delete $log->{path};
  # i.e.,. handle was actually created and is *not* STDERR

$log->path($log_path);
$log->append($log->format->(@$_)) for @{$log->history};
    }

and you'll notice I'm relying WAY too much on the implementation of Mojo::Log.

I'm not certain what the Right Thing is here.
It's possible some or all of the above should be rolled into log->path(newpath)

(... One way out of the box that I'd explicitly reject would be an option to to suppress logging during Config plugin load, which seems like the Wrong Thing since if something happens during Config plugin load that somebody deemed worth logging about, I'd probably want to know about it.  At most you'd want to defer it but even then you're risking that the application will crash before anything gets written... the very situation you'd WANT something in a log file...)

sri

unread,
Jun 22, 2016, 9:17:41 PM6/22/16
to Mojolicious
This reads more like a rant than a question. If you want to propose changes to our config plugins, now is the time. We are currently preparing the 7.0 release, which means all kinds of breaking changes are on the table.

--
sebastian

sri

unread,
Jun 22, 2016, 9:34:25 PM6/22/16
to Mojolicious
If you want to propose changes to our config plugins, now is the time. We are currently preparing the 7.0 release, which means all kinds of breaking changes are on the table.

I've removed the log message for now.


--
sebastian 

Roger Crew

unread,
Jun 23, 2016, 11:07:22 PM6/23/16
to Mojolicious


On Wednesday, June 22, 2016 at 6:17:41 PM UTC-7, sri wrote:
This reads more like a rant than a question.

Sorry, not intending to rant.  Status quo might not be ideal, but I meant it when I said "I'm not certain what the Right Thing is here," which then entails a certain amount of thinking out loud in hopes that someone with more insight will chime in with a sensible proposal (which is also why I didn't put it on the wishlist thread).
Reply all
Reply to author
Forward
0 new messages