•Re: File tracking

Here's what I'm using to rotate logs on my new shiny website:

#!/usr/bin/perl -w
use strict;
$|++;

### Processed automatically at 10:29:34 21-Jun-2002 from              
+     ###
### sbin/log-roller.tmpl edited at 07:58:15 17-May-2002               
+     ###

my $PIDFILE = "/web/stonehenge/var/run/httpd.pid";
my @LOGS = glob("/web/stonehenge/var/log/*_log");

## first, compress any old log files

if (my @OLDLOGS = grep -M > 7, glob("/web/stonehenge/var/log/*[0-9]"))
+ {
  system 'gzip', '-9', @OLDLOGS;
}

## then, get the PID

open PIDFILE, $PIDFILE or die "Cannot open $PIDFILE: $!";
chomp(my $pid = <PIDFILE>);
close PIDFILE;
$pid =~ /\d+/ or die "$pid doesn't look like a pid from $PIDFILE";

## now roll the logs

{
  local *ARGV;
  local $^I = "." . time;
  @ARGV = @LOGS;
  close ARGV while <>;          # quick rename while emptying
}

## finally, let Apache know we've messed around

kill 'USR1', $pid or warn "Cannot send USR1 to $pid: $!";
[download]

That last step is critical. There must be some way to let the writer know that the file they have open is now a new file.

-- Randal L. Schwartz, Perl hacker

Comment on •Re: File tracking Download Code

Replies are listed 'Best First'.
Re: •Re: File tracking by r (Initiate) on Jul 06, 2002 at 17:35 UTC
Deeply appreciating your advise and sharing of wisdom I have to confess in meekness that my question apparently has not been put in a sufficiently stringent manner. To make it clear now, the mentioned server is no Apache, and I am not in the position to change the logfile rotation procedure in this productive system :-( I will pose some subquestions to clarify: 1) Is my implementation of "tail -f" neat enough? I think so. 2) Assuming that logfile rotation is working correctly, is the reopening of the current logfile done properly assuring no loss of data? 3) The real whole problem - how to manage the following possibilities: a) rotated logfile with altered name may still be the active, no logfile with the original name present -> No problem (see inode comment in source) b) at some indefinite time a new logfile with the original name becomes the active one -> Point 2 I ask for patience and balminess, bearing in mind my own weakness. -r	[reply]
Re^3: File tracking by ehdonhon (Curate) on Jul 06, 2002 at 18:57 UTC
Is my implementation of "tail -f" neat enough? I think so. I don't know if sleep/poll cycles are the most efficient way of doing things here. You might want to try using select if you can. ... is the reopening of the current logfile done properly assuring no loss of data I'm not sure.. imagine this scenario: Your process scans the logs. Your process sleeps. While you are sleeping, the server outputs the bad error lines. Still while you are sleeping, the logs get rotated. When you wake up, you'll start processing the new file and never see the error lines.	[reply]
Re: Re^3: File tracking by r (Initiate) on Jul 06, 2002 at 19:35 UTC
Thanks a lot for the first concrete steps towards a work around - work forever solution regarding lifetime of certain servers. I am aware of sleep being the possible "loss of data" - period, your scenario explains the problem excellently. Besides, I am stopping and re-starting the server because no other action (kill -HUP, native restart) solves the hang-up. What would be your approach (using select)? Be the munk that enlightens my soul and mind :-) -r	[reply]
Re: •Re: File tracking by Juerd (Abbot) on Jul 06, 2002 at 18:01 UTC
$pid =~ /\d+/ or die "$pid doesn't look like a pid from $PIDFILE"; Does `QWERTY123` look like a pid then? :) `$pid =~ /^\d+\z/ or die;` [download] - Yes, I reinvent wheels. - Spam: Visit eurotraQ.	[reply] [d/l] [select]