in reply to Re: cleaning up logs
in thread cleaning up logs

Thanks for pointing this out. I didn't think to add the fact that the file is still opened and any data that goes to it after that point will not go through the filter.

The assumption I made was that the file was written to in a chronological order, so anything that was coming in while the script was running should be under the 30 day limit that was mentioned in the original post. This would make the point that the filter dosen't see this new data moot.

Replies are listed 'Best First'.
Re: Re: Re: cleaning up logs
by BrowserUk (Patriarch) on Oct 07, 2002 at 19:58 UTC

    My point was that using Perl -i on an open file won't work as it will try to rename that file and create a new one with the old name. The rename will fail.


    Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
      Are you sure it works like that? I tried the example below and it worked fine? Am I missing something?
      perl -e 'open(FILE,"./syslog") or die "Cannot open syslog: $!\n"; slee +p 1000000000;' & then perl -i -p del.pl ./syslog

      This worked fine, next I tried this:

      perl -e 'use Fcntl;open(FILE,"./syslog") or die "Cannot open syslog: $ +!\n";flock(FILE,LOCK_EX); sleep 1000000000;' & then perl -i -p del.pl ./syslog

      A 'ps' both before and after the -i command showed the opening of the local syslog file active. Both with and without the flock worked fine. Please let me know if I am missing or misunderstanding something about the file locking?

        You have a file (say syslog), it is open by a process (say logger) and logger is writing to it.

        A second process (perl) comes along and renames the file to syslog.bak and opens a new file called syslog it then proceeds to read lines from syslog.bak and selectively copy some of them to syslog, Process logger is still writing to syslog.bak. The perl script finishes processing, closes syslog.

        What have you achieved? The log file that logger is writing to still contains all the lines it had to start with. You have a new file with a subselection of those lines, and have possibly archived the rest somewhere, but the file logger is writing to is still as big as it was originally, and growing. You have no way to remove those lines you archived from the original logfile, and no way to persuade logger to use the new shortened version of the file without stopping and starting logger?

        Below are the results I got when I tried this on my (Win32) system. Maybe the results are different on *nix, but the fact that the logger process continues to use the unchanged, unshortened version of the file isn't?

        C:\test>type logger.pl #! perl -sw use strict; use POSIX 'strftime'; $|++; #! Sat Aug 31 23:13:46 CDT 2002 while (1) { sleep 1; print strftime( '%a %b %d %T %Z %Y',localtime), "@{[times]}", +$/; } C:\test>logger Mon Oct 07 BST 20020.18 0.04 0 0 Mon Oct 07 BST 20020.18 0.04 0 0 Mon Oct 07 BST 20020.18 0.04 0 0 Mon Oct 07 BST 20020.18 0.04 0 0 Mon Oct 07 BST 20020.18 0.04 0 0 ^C C:\test>^Clogger >log # different session C:\test>dir log Volume in drive C has no label. Volume Serial Number is 8C87-E163 Directory of C:\test 02/10/07 09:59p 980 log 1 File(s) 980 bytes 25,827,328 bytes free C:\test>dir log* Volume in drive C has no label. Volume Serial Number is 8C87-E163 Directory of C:\test 02/10/07 09:59p 1,120 log 02/10/07 07:17p 186 logger.pl 2 File(s) 1,306 bytes 25,827,328 bytes free C:\test>perl -wni.bak -e "print if /7/;" log Can't do inplace edit on log: File exists. C:\test>perl -wni -e "print if /7/;" log Can't do inplace edit without backup. C:\test>

        Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!