>any usual logrotate script I've come across would send a SIGHUP to the
appropriate process
Thanks for you input. I tried manually emulating the logrotate script by
moving the log file and then sending the kill -HUP to the processes.
Unfortunately only one of several processes writing to the same log responds
correctly, so now we have some log entries appearing in the moved file and
some log entries going to a new file by the correct name. I've sent a
question off to the product support folks, but my guess is it will take a
while, if ever, for those processes to be fixed to respond to SIGHUP.
The other question is, am I taking the right approach? When I said "edit
in-place" I really meant it, but so far these techniques are simply creating
another file. I thought that the technique I used was supposed to be edit
in place, but that might not be true. I have found a sample in the "Perl
Cookbook" that uses an array to bring the whole file into memory then write
it back out after making changes. This I don't think will work for us, as
the size of the file gets very large very quickly.
0) How large is too large for processing the file in memory? I expect our
files will easily be 25,000 lines each weekday
1) Is it even possible to actually edit "in-place" without changing the
inode number?
2) Is this the proper technique for edit "in-place" and I'm doing something
wrong? or is there a different way to implement that would not change the
inode number of the file I am operating against?
Here's the snip of my perl code again. :
open (LOGCOPY, ">${logcopy}") or die ("Cannot open $logcopy \n");
@ARGV = ("${logdir}/${logfile}"); # prime the diamond operator
$^I = ".bak"; # write $logfile.bak for backup
while (<>) {
if ($todayfound eq "y") { # if today's date has already been
found
print; # write to ARGVOUT, the new logfile
} elsif (m/($weekday)\s+ # match for today's weekday, spa
($month)\s+ # and today's month, spaces
(\d+)/x # and one or more digits
and $3 == $day){ # and digits are day of month
$todayfound="y"; # then set flag for date found
print; # write to ARGVOUT, the new logfile
} else { # if we have not reached today's date
print LOGCOPY; # write the line to the logcopy file
s#.*\n##; # erase the line
}
}
close (LOGCOPY);
BTW this log data is not critical, so I feel no need to lock the file. If
it takes a few seconds to process it and one or two lines from the running
processes are lost it would not be a big deal, although if we do the log
processing at night there will be very low odds that anything would be lost.
The main problem is that the users like to reference it, and it grows so
fast that it is unwieldy for them and takes up a lot of space. The intent
is that the processes should remain up and running for several months at a
time, so shutting down is not an option.
Thanks again,
Beth Rice
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
