can I see a log of what the crontab actually did?

newbiesforever · 06-27-2020, 06:09 PM

I put some backup procedures in the crontab. Is there a log somewhere of whether the crontab actually executed them? It would make me feel better if I could see proof at least once and know it didn't go wrong.

frankbell · 06-27-2020, 07:53 PM

A web search turned up lots of confusing stuff about cron logs, but, if MX does not have a /var/log/cron file, my best guess is to check /var/log/syslog. (I have a VM of MX, but I'm not running any cron jobs on it.)

This might help: https://www.cyberciti.biz/faq/how-to...-ubuntu-linux/

kilgoretrout · 06-28-2020, 09:15 AM

By default, crontab will send email to the user's account(user@localhost) every time a cron job runs. For this to properly occur, you need to have some MTA(message or mail transfer agent) installed to send the email. The two most common are Postfix and Sendmail. If you install Postfix just go with the defaults and crontab should be able to send email. To read crontab's email messages, install mutt, a command line email reader. Note, neither mutt nor Postfix are usually installed by default.
Now for reading your crontab messages, just open a terminal and run:

Code:

$ mutt

if you are running crontab from your user account or

Code:

$ sudo mutt

if you are running crontab from the admin account. Here's what it looks like on my box:

Code:

q:Quit  d:Del  u:Undel  s:Save  m:Mail  r:Reply  g:Group  ?:Help
   1     Jun 28 Cron Daemon     (  88) Cron <patrick@Fortress> /home/patrick/bin/desk_cron




---Mutt: /var/mail/patrick [Msgs:1 Post:1 3.6K]---(threads/date)---------------------------------------------------------------------------------------------------------------------(all)---

Selecting the email message you're interested in will give the complete output that the cron job generated when it was run like so

Code:

i:Exit  -:PrevPg  <Space>:NextPg v:View Attachm.  d:Del  r:Reply  j:Next ?:Help
Date: Sun, 28 Jun 2020 08:35:35 -0500 (CDT)
From: Cron Daemon <root@Fortress.attlocal.net>
To: patrick@Fortress.attlocal.net
Subject: Cron <patrick@Fortress> /home/patrick/bin/desk_cron

receiving incremental file list

sent 132 bytes  received 118.62K bytes  237.50K bytes/sec
total size is 65.46G  speedup is 551,279.97
receiving incremental file list

sent 26 bytes  received 2.20K bytes  4.46K bytes/sec
total size is 14.44G  speedup is 6,478,651.74
receiving incremental file list

sent 81 bytes  received 16.22K bytes  10.86K bytes/sec
total size is 29.66G  speedup is 1,820,045.18
receiving incremental file list

sent 26 bytes  received 1.30K bytes  884.67 bytes/sec
total size is 17.32G  speedup is 13,051,676.07
receiving incremental file list

-   - 1/1: Cron Daemon            Cron <patrick@Fortress> /home/patrick/bin/de -- (24%)

You use the space bar to scroll through the message. Crontab will send out a separate email every time a cron job runs and you can easily see if something is amiss with your backup cron job.

rnturn · 06-28-2020, 11:00 AM

Quote:

Originally Posted by newbiesforever

I put some backup procedures in the crontab. Is there a log somewhere of whether the crontab actually executed them? It would make me feel better if I could see proof at least once and know it didn't go wrong.

There's always email. Add the line:

Code:

MAILTO=your-email-addr@your-hostname

to your crontab (I place it near the top) and you'll receive an email after the cron job completes that contains the output from your backup script. It's helpful to add "2>&1" to the end of the command you are using for the backups. The downside to this method for root's cron jobs is that "your-email-addr@your-hostname" will receive all of root's cron job emails. Probably not desirable (though someone ought to be reading those).

An alternate method of receiving that email notification (and I lean toward this one) is to pipe the output of the backup script into mailx (or similar)

Code:

00 02 * * * run_backups 2>&1 | mailx -s "BACKUP Results" user-who-monitors-backups@your-hostname

If you have different users who are in charge of different aspects of the system, this allows you to have messages going to specific people (rather than subjecting an individual (or group) to the potential firehose created by the MAILTO variable). If you have a backup team, you can define an email alias (example: "backup_admins") in "/etc/aliases" containing the list of backup admins' email addresses and specify that alias in the email command.

Code:

00 02 * * * run_backups 2>&1 | mailx -s "BACKUP Results" backup_admins@your-hostname

Dedicated storage team? Same thing can be done for those folks.

HTH...