2

I have a series of cron jobs on a server machine. I know I can redirect their stdout/stderr output to a file. If I redirect several cronjob outputs to the same file, will that work even if some of the jobs might be running at the same time?

3 Answers 3

3

No, it's likely that they will overwrite each other.

As a simple method add

[email protected]

at the top of the crontab, then cron will email any output to you.

A more complex method may involve setting up cronolog listening on a FIFO then sending the output of those scripts to the fifo. This would take some care and handling, if the FIFO goes down then your cron jobs will block writing to it.

To be honest, I prefer cron jobs that output nothing unless there is a problem, in which case MAILTO lets me know.

3

even simpler method is to pipe all output into 'logger' tool and log to syslog, i.e.

* * * * * cronjob1.sh 2>&1 | logger -t cronjob1
* * * * * cronjob2.sh 2>&1 | logger -t cronjob2

then look in /var/log/messages

the disadvantage is that this is machine wide and you have to be root to be able to see the log, although it is possible to set up separate syslog files with user accessible permissions.

0
0

After reading many posts such as this one, I found there is no unified logging for cron. For most of us, enterprise workload schedules are not an option and the most frequest advice is to use logger and/or send output of your scripts via email or append output to a file. Useful logging and alerting is something none of these techniques can achieve. So, I wrote wrote a Perl script that I shared on GitHub that solves:

  • email logging/alerts: problematic because if your script is noisy, it will spam you and you will stop paying attention to those email messages

  • logger: logs to syslog - how do you know if your script succeeded or failed? is the absence of errors indicative of success?

  • logging to file - same as logger but means you have to set up your own log rotation

  • alerts when there is a particular failure (non-zero exit code, exit due to catching a signal, output on STDERR/STDOUT)

Check it out. It works and its free: https://github.com/ttubiak/utils/blob/master/bs

Its called "BS" (baby sitter) and you are welcome to use it/adopt it. In summary, it's a "parent" script that runs your program as a child process. You tell it what to run and it will run it for you with meaningful logging and flag file generation if your script runs into issues. It works by attaching itself to your program's STDOUT and STDERR and waiting for your program to finish running. When bs starts your program, it will use syslog to say so, when your program/script writes to STDOUT/ERR it will log that to syslog and, if you choose so, write to a file which you can monitor. If you program dies, it will naturally log this information via syslog and create a flag file for which you can monitor. Additionally, it will log a line of statistical information via syslog so you know how long your code takes to run. There are more advanced things it can do in conjunction with a Nagios check, which I intend to post in time.

You must log in to answer this question.