Cron – Being notified via email of errors in cron jobs

cronemail

You would like to be notified via email of errors occurring while executing cron jobs.

I use CentOS and the file /etc/crontab for the configuration.

The first step I have done is:

MAILTO=my_email_address

and then I have appended this to each crontab entry:

2>/dev/null

That means this

24 4 * * * root /usr/sbin/ntpdate pool.ntp.org

becomes:

24 4 * * * root /usr/sbin/ntpdate pool.ntp.org 2>/dev/null

In that way I should suppress the normal output and let error messages be sent.

I would like to know if you think what I have done is right and whether that has got any pitfall.

Thanks,
Dan

Best Answer

Actually, I think you've done the exact reverse of what you wanted; you've suppressed the error messages (by sending STDERR to /dev/null) and will get only the normal output.

Try

24 4 * * * root /usr/sbin/ntpdate pool.ntp.org > /dev/null

Better still, run ntpd; it's a much better way of keeping your clocks in sync than brute-force resetting them once a day.

Related Solutions

Cron – How to write integration tests for cron jobs

Best practice is to do all your testing in a development environment (which you already seem to know).

For testing cron jobs I generally don't like to muck around with the system clock (you can't just step the time to wherever you want - You need to let the clock run through all points to see how the jobs run and interact with each other.
You also can't just speed up the clock (x100) to make it faster: cron jobs that do a lot of number crunching won't be any faster, and you may have them stepping on themselves (or each other) depending on what the schedule looks like.

My standard for testing cron jobs is as follows:

Test the job by running it manually.
Debug the hell out of it here so you don't get bombarded with cron email later.
Install the job, schedule it to run 2-3 minutes from now.
- Observe the results running from cron (with no tty).
Break something the job relies on and schedule it to run again in a few minutes.
- Observe the reaction to breakage (make sure it does what you want).
If the job runs OK in (2) & (3) schedule it to run at its normal time.
- Observe the results of the job running at its normal time.
- If the job runs OK promote the change to production.

In practice you can skip step 4 sometimes (if you KNOW that a job doesn't impact any other jobs and you're not worried about CPU/RAM/Disk load issues).

To really do an integration test on cron jobs you have to let a full year elapse (daylight saving time changes), and an argument can even be made for needing more than 4 years (leap years, leap seconds, etc.), but nobody I know does this. Just be aware that sometimes 2:30 happens more than once (or doesn't happen at all), and that there isn't always a February 29th and you're usually fine.

Linux – Cron Job not running ( too many open files )

This isn't a problem with your script, it's a problem with your system. As you might guess from the error, there seem to be too many files open.

Check /proc/sys/fs/file-max to see what your limit currently is. If it's too low, you can reset it using sysctl. Also, add a line to /etc/sysctl.conf to set it at your next boot:

file-max=65536

(for example)

Best Answer

Related Solutions

Cron – How to write integration tests for cron jobs

Linux – Cron Job not running ( too many open files )

Related Topic