Is any extended logging available for cron jobs

cronlogs

I have 3 scripts under /etc/cron.daily.
My cron logs are written in /var/log/cron. The below is an entry for the above cron that has run.

(root) CMD (run-parts /etc/cron.hourly)

Here the stdout or stderr of the scripts inside the cron is unavailable, it shows that run-parts command has run over this folder.

Is there any tricks that can help to log what happened while the 3 scripts were executed?

NOTE: I cannot edit the scripts in cron.daily to redirect outs and errs to a log file.

Best Answer

On Unix the mail system is the means by which system notifications get delivered to users. You can think of it as sort of like on Windows where something will show in your taskbar with a popup message if it needs to notify you of something. Since cronjobs (theoretically) shouldn't produce any output (since no one should be there to see it) any output (stdout or stderr) is treated as if it's a possible indication of an error or issue and so an email is sent to the cronjob's owner to prompt them to check it out.

So, all output (stdout and stderr) is sent through the local mail system to the cronjob's owner. If the owner is a non-personal account you can direct the local MTA to relay to a real email account by setting up an alias. For example, I added to /etc/aliases:

root: joel.davis@xxx.com

Then ran the newaliases command (to rebuild mail aliases database). After that, I started to receive root's email's in my corporate email's inbox:

root@xxxxxxvlp05 ~ $ echo "the game" | mutt root -s "No Diggity"
sendmail: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol
sendmail: warning: inet_protocols: configuring for IPv4 support only
postdrop: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol
postdrop: warning: inet_protocols: configuring for IPv4 support only

Look at it in all its glory

So that's the more or less normal way (letting the system send notification emails). There are other means of dealing with the notification. A few alternatives:

Modifying aliases to save the emails to a particular file:

root: /var/log/rootMails

Piping the mail to a script:

root: |/usr/local/bin/filterMail

An alternative to messing with aliases is to use the MAILTO= option inside the user's crontab that many cron daemons support. This might be preferable if you only want to receive a particular set of the user's notifications, and not anything that will get dropped into their mailbox (which is what aliases accomplishes).

I'm sure there are plenty of others, but you probably want to do the first or last ones, though.

Related Question