AIX > Tips & Techniques > Miscellaneous

Unsubscribe From Crontab Emails


If you’re managing a system running AIX, chances are you’re on the receiving end of a lot of email alerts. If these are coming from scripts that are set up to run in the cron scheduler, it can be very difficult to keep on top of these emails.

You sometimes wish these email alerts had an unsubscribe button. Maybe you’ve set up a rule in your email client to send them to a folder that you never look at, which kind of defeats the purpose of alerts.

Here are eight things you can do to reduce the email clutter from scripts that are scheduled via the AIX cron scheduler.

1. Send emails to a list, not a person

Like it or not, you probably won’t be in your present role forever. When people move on from a company – or simply change to a new role – what happens to all of those email alerts that are set to the system admin’s own email address? It makes a lot of sense to set up a group in your email server, even if you’re the only one in the group. If you know that your alert emails all go to support@acme.com, for example, when there are changes of personnel and responsibilities you only need to change who’s on that list to ensure it gets to the right people.

2. Check the cron daemon log file.

On AIX, the cron daemon by default sends its output to the log file /var/adm/cron/log. This is different from any output that a script you call may generate.

A quick look at this text file can show you cron jobs that have run – or have failed.

Look at this one:

root      : CMD ( /usr/local/bin/myscript.sh  ) : PID ( 1306878 ) : Mon Dec 28 09:25:00 2015
Cron Job with pid: 1306878 Failed

The reason this job failed was because the script /usr/local/bin/myscript.sh didn’t exist. Maybe the script was moved or deleted some time after it was initially set up to run in the crontab, but the crontab entry never got updated.

You’d be surprised how often scripts get set up in the crontab (using crontab –e) but never complete successfully. Still, they may send emails every time they run. And if that’s happening hundreds of times a month, there’s a chance those emails are simply adding to the clutter of alerts. A quick look at the cron daemon log file from time to time will help you identify and kill all these non-performers.

3. Turn off broken scripts

The scripts may be broken, because they don’t exist in the path, have the wrong permissions or are simply checking some system metric that is no longer relevant for your environment. I’ve seen scripts that are set to enable a print queue every five minutes, and that job keeps running years after the print queue has been decommissioned. It ran over half a million times a year.

Once you’ve established that the script doesn’t ever run properly, then either fix it or remove it from the crontab.

4. Include source and hostname in the script output

It can be especially frustrating to receive alerts which you don’t need, but you don’t know how to turn them off because you don’t know where they’re coming from.

Here’s a preventative rather than a cure for that problem.

When you receive an email alert you can lose a lot of time tracing exactly where an error has come from. If you’re writing a shell script, it’s a good idea to add some detail to the output so that it’s easy to find what generated that alert.

Here’s a simple way of doing that.

Add a line in your script that includes the date and time the script was run, as well as the host name and the name of the script. Use $0 to show the script name.

echo “This was created by $0 on $(hostname) at $(date)”

There’s a lot more you can do with the format of that line, such as reformatting the date output, but this step alone will help you identify where emails have come from.

5. Use exception reporting

Instead of sending an email every time a job is run, it makes sense to send it only when there’s a failure. This will depend very much on the importance of the job, and what the business impact will be if it misses a run for some reason. Remember, the fewer emails you get that you have programmed yourself to ignore, the more focus you can give to the ones that you need to do something about.

6. Reduce crontab frequency

Even if you do have cron jobs that run very often, you may find it worthwhile spacing them out, even a little. It’s pretty rare to have to run a cron job every single minute of every day, especially if there is another way of running the process, such as via an application scheduler. A crontab job that is set to run every 15 minutes, 24 X 7, will run over 35,000 times a year, so it’s worth reviewing every single crontab entry from time to time.

7. Don’t test with crontab

This is a big one. I sometimes see people testing a script to be sure it will run without user intervention, and they do that test by adding the script to the crontab. This is a recipe for a cluttered crontab, which simply slows you down when you’re doing troubleshooting.

For one-off jobs, use the AIX at command. The syntax is very easy:

at   3   pm   Friday
/usr/local/bin/myscript.sh
<Ctrl-D>

You can even scheduled a job to run immediately using “at now”. Here’s how:

echo “/usr/local/bin/myscript.sh” | at now

It’s surprising how few people use the at command. It’s a much simpler way of setting up jobs without cluttering a crontab.

8. Use an application scheduler

Many applications have their own scheduling functionality. This is usually a much more user-friendly way of setting up jobs and changing the times they run.

By decluttering your crontab, and reducing unnecessary email alerts, you can simplify your system admin work, start to declutter your inbox and buy back a whole lot of time.

Cron daemon configuration and log file
https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.cmds1/cron.htm

Submit, edit and list cron jobs with the crontab command.
https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.cmds1/crontab.htm

Schedule a job to run at a later time with the at command.
https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.cmds1/at.htm

Anthony English is an AIX specialist based in Sydney, Australia.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

AIX > TIPS & TECHNIQUES > MISCELLANEOUS

Application Testing: Giving Users What They Need

AIX > TIPS & TECHNIQUES > MISCELLANEOUS

Change Management: Approval Must Be Earned

AIX > TIPS & TECHNIQUES > MISCELLANEOUS

Making Changes: Prudence and Discipline Always

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters