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
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
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:
Piping the mail to a script:
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
I'm sure there are plenty of others, but you probably want to do the first or last ones, though.