Managing your Logs with Chklogs
Once you have created your first configuration file, you need to have Chklogs initialize its internal database (not to be confused with configuration) specified by either the configuration variable ResrcFile (for historic reasons) or the Personal Resource File's ChklogsDb variable. Remember, initialization overwrites any previous history so should be done only after the first installation (rather than when you make changes to add/remove logs/groups). Use the following administrative command:
Then, issue the administrative command:
chklogsadm initreposto initialize all the alternate repositories. Unlike init, you must execute this command each time you create a new group or change the location of your alternate repository (the global parameter). All of these steps are explained in detail in the documentation provided with the package.
Finally, the sync option of chklogsadm is needed whenever you make a modification to the configuration file (chklogs.conf). This is not done automatically because it is not very effective if several modifications are made to the file consecutively. This operation is as simple as typing:
Chklogs comes with several plug-outs. I use them to generate statistics on my UUCP logs, listserver log, etc. You can build your own plug-outs, and in fact I would like to hear about any log scanners or filters you have. Available plug-outs are stored in the /plug-out and /contrib directories.
A plug-out is any external program executed by Chklogs in the Pre/Post group directives or the execute actions. This program must not generate any output on stdout/stderr as it will clutter the report, and if you, like most users, run Chklogs with a cron job, then this sort of behavior is undesirable. So, do you have a nice scanner that does write to stdout/stderr and don't want to hack it up? Or don't know a thing about programming? Simply use the cdkwrap wrapper provided in the distribution, and it will capture all the output and mail it to you.
Also, the plugged-out child inherits certain environment variables that provide useful information:
CDKLOG: The fully-qualified log name
CDKROOT: The archive repository
CDKMAILTO: The e-mail address for mailing the report
Now, we have finished our setup; we have a configuration file, a resource file and initialized repositories. The administrative tasks are done for now (you can make changes later, if needed), and we are ready to get down to the action. Chklogs has several command-line options, some of which can be combined to achieve a particular effect. I won't cover all of them, or even all of the possibilities, but I will discuss enough of them to enable you to begin, and to acquaint you with a few of its capabilities. Note that we will now be using the chklogs program, not the administrative program, chklogsadm.
Basically, there are four major actions you can perform:
Check the configuration file.
Get an overview of all the logs that are archived.
Obtain a report of actions to be taken when you execute the program.
Perform the actions as directed on the configuration file.
To check the correctness of the configuration file (although the check is not very thorough) use the following command:
For a quick overview of which logs are archived into the repositories, there is the -l command line option:
chklogs -lThis gives you an indication of how many logs you need to scan or filter and needed information in case something suspicious happens on your system.
To get the usual log report indicating whether a log is still within its threshold, and if not, what action would be performed, use the -w option:
chklogs -w [-m]
Alternatively, you can also specify the -m (mail) option to mail the report. You cannot put them on the same switch (-wm).
Finally, when you want Chklogs to actually process your logs as specified in the configuration file, simply use it without any of the above options:
A report is produced on standard output unless you use the mail (-m) option. Mail is the most frequently used option.
Most users make an entry into the /etc/crontab file so that Chklogs runs every day at a particular time and mails the report. A typical crontab entry looks like this:
# System Cron Tab 45 23 * * * root /usr/local/sbin/chklogs -m
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released