http://www.perlmonks.org?node_id=1063147


in reply to Search logs with crontab

I might also add, that you could put your script into a sleep for 2hrs. time, before running again. Thereby eliminating the repetitive mail(s) cron sends.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

Replies are listed 'Best First'.
Re^2: Search logs with crontab
by hmb104 (Sexton) on Nov 18, 2013 at 17:04 UTC

    The 2 hours sleep will not help me here. The script will still run and catch the same old logs it did before and email me about them. How can I search only from that specific time and onward?

      Take a look at the seek function.

      If I understand you correctly. That was my point. Given that cron will alert you every time it fires off your job, with a message indicating the results. It seemed quite pointless to use cron to manage your script (for the most part). I thought it better, since you're already utilizing sendmail to deliver the outcome of your script. Why not fire your Perl script, and let it manage the schedule thru sleep. Maybe via a for loop, or something. You could capture the entire process via print, or simply redirect <, > the output/results to a file, and have sendmail send it to you, via attachement, or some such thing.

      Best wishes.

      --Chris

      #!/usr/bin/perl -Tw
      use Perl::Always or die;
      my $perl_version = (5.12.5);
      print $perl_version;

      The idea is, you save the size of the file that you've checked at one point of time, and then next time you skip this much of data before you start looking for your string. Then you don't need to modify anything in the file.

      The easiest way to do it is to let perl run forever, letting it sleep for 2 hours and then repeating the loop. Then you can keep the old file size simply in a variable. Beware, if you restart the script, you'll loose the offset.

      If you insist on running perl from crontab, then you'll have to save the size in some file and then on startup read that file to obtain the offset of data where searching should start.

      Note, there's still one catch here. Most likely the log file is rotated periodically, so your program should be smart enough to notice that log file was rotated and reset the saved offset.

      As to your original approach with replacing strings, this also can be done, but this requires opening file in "read-write" mode open(FILE, "+<mylog.file"). Then you would mark position of the string which you want to replace, then seek to that position using seek function and then write the new string. Though you should be careful not to change the length of the string, otherwise you'll corrupt other data as well. After you are done writing, you would seek again to the position where you stopped reading and continue.

      As you can see, that approach is somewhat complex, plus it is inefficient, because you'll have to scan through the same areas multiple times. The only benefit here is automatic handling of log rotation.

        "As to your original approach with replacing strings, this also can be done, but this requires opening file in "read-write" mode open(FILE, "+<mylog.file")."

        There's also a potential "gotcha" here. That being; permissions. The subject file (in +RW) will require the maintenance of not only the current RWX bits, but that the script implementer has sufficient rights, and doesn't change ownership of said file.

        All in all, seems keeping markers in a separate file would probably be the most sensible approach -- FAR less overhead.

        --Chris

        #!/usr/bin/perl -Tw
        use Perl::Always or die;
        my $perl_version = (5.12.5);
        print $perl_version;