Logcheck on Fedora, for my use

Logcheck on fedora, by default when installed, runs every hour. For my use this generates so much email traffic (as it runs on all my servers) that it becomes garbage, and I ended up just deleting all the emails rather than reading them.

In reference to the garbage, by garbage I mean that running hourly, against the same log files, resulted in the emails being sent containing pretty much duplicate information from the prior run; pointless. Yes I could change the time parameters but I don’t want the emails every hour anyway.

So I decided to change it from hourly to daily, while that does not mean I will read them all it does mean I have a chance to actually check other emails from other subsystems that tended to be deleted while I was bulk deleting the logcheck ones.

The scheduling for logcheck does not reside in /etc/cron.hourly to be simply moved to /etc/cron.daily to be run whenever /etc/anacrontab decides to run it during the defined day, it is actually in a file /etc/cron.d/logcheck to run at a specific time.

Point of interest: files in /etc/cron.d are similar to, but not the same as normal crontab entries, the main difference being there is a requirement to specify the userid a job is to be run as. The interesting point however is that files in /etc/cron.d also have the interesting property of being able to be scheduled to run at ‘@reboot’ rather than a specific crontab format time such as ‘2 * * * *’, which I may find a use for at some point.

So I simply changed the default scheduling time in /etc/cron.d/logcheck from ‘2 * * * *’ to ‘2 2 * * *’ to run at 2:02am daily rather than at two minutes past every hour.

I also have found a need to create custom suppression filters, which will be an ongoing work in progress, those rules also need to be copied to all my servers.

So as this affected all my servers I created a puppet class for logcheck and added it to the ‘base’ profile, and added it to my generic ‘allservers’ role that contains common configurations and packages needed on all servers. This will ensure all servers are correctly setup as I was starting to lose track of which ones I had manually updated the cron.d entry on, and now I am creating custom filter rules that will be updated fairly regularly I just want to update everything from one place, which puppet lets me do.

While some may think the simple change to scheduling time was probably not worth a post, I think the ability to use ‘@reboot’ as a scheduling time option in files under /etc/cron.d has potential, which many of you may not have known about had you not read this pointless post. Irritatingly I knew that function existed but had forgotten about it, so pherhaps this post is more a reminder to me :-)

About mark

At work, been working on Tandems for around 30yrs (programming + sysadmin), plus AIX and Solaris sysadmin also thrown in during the last 20yrs; also about 5yrs on MVS (mainly operations and automation but also smp/e work). At home I have been using linux for decades. Programming background is commercially in TAL/COBOL/SCOBOL/C(Tandem); 370 assembler(MVS); C, perl and shell scripting in *nix; and Microsoft Macro Assembler(windows).
This entry was posted in Unix. Bookmark the permalink.