I want to troubleshoot a cron job that worked fine until a recent modification, but I can't find the cron log file, where is it?
-
2Is it really a cron job or are you using launchd. Cron has been deprecated on OS X. – jaberg Jan 31 '12 at 17:29
-
1Did you set a log file for the cron job? – daviesgeek Jan 31 '12 at 17:32
-
it is actually a `cron` job I set it up with `cron -e` and I can see it with `cron -l` and I am sure it worked on Lion and before that on Snow leopard for a long time. – Ali Jan 31 '12 at 17:54
-
and no, I don't manually set a log file for 'cron' itself, although I write to a log file inside the job and it has stopped working recently after I changed something. – Ali Jan 31 '12 at 17:55
-
2Ali, Since you have the answer, please post it as an answer and accept it. Do not edit it into the question. You are not only allowed, but encouraged, to answer your own question. – Jason Salaz Feb 01 '12 at 17:12
5 Answers
By default, cron does not log output of executed jobs. It is possible to log the fact that cronjobs have been executed, but that is not the default on OS X either.
In order to investigate cronjob execution output, I suggest modifying your cronjob line to redirect STDOUT and STDERR to logfiles. In your crontab file or after running crontab -e, however you go about it, add something like the following to your job line:
0 0 * * * yourcommand >/tmp/stdout.log 2>/tmp/stderr.log
Doing this should send STDOUT (normally printed or echo'ed output to STDOUT) to a text file named stdout.log in the /tmp directory, and STDERR to stderr.log in the temp directory. Many utilities use STDERR to print special error messages out when they're application errors, and not errors generated by the program's actual execution. (You can read more about STDERR on Wikipedia.)
- 23,691
- 18
- 96
- 147
-
Thanks, that's exactly what I have been trying to do, it looks like that `cron` for some reason fails to run the job in the first place. if I run the job myself by typing the command in the terminal it runs and outputs to the logfile but if I wait for the `cron` to run it nothing happens, at least no change in the log file, I was thinking maybe a "cron log file" or there was any traces in the consol it could help me find out what is going on, recently I changed my shell from bash to zsh but I don't think that could have affected this either. – Ali Jan 31 '12 at 18:16
-
1According to http://erikslab.com/2011/02/04/logging-with-launchd/, you could modify the cron plist (`/System/Library/LaunchDaemons/com.vix.cron.plist`) with a Stdout/Stderr path to debug cron itself. I don't recall if `launchctl unload`ing and `launchctl load`ing the plist is sufficient, or since it's a system daemon if you'd have to restart entirely. I'd suggest the latter just to be sure. – Jason Salaz Jan 31 '12 at 18:28
By default, "logging" is not enabled. But you may get some useful information by running the mail command.
TL;DR on the mail command: press enter to read messages, and then q and enter to quit.
- 1,611
- 2
- 19
- 29
-
4Very good, thanks. Mine showed me that there was an unrecognized command with my Cron. Cheers! – Joshua Pinter Apr 19 '16 at 22:47
I was able to find cron-job log in,
/var/mail/{user-name}
Following is a cron job log I got for running an AWS CLI command,
From build@BuildServer1.local Fri Mar 2 10:00:00 2018
Return-Path: <build@BuildServer1.local>
X-Original-To: build
Delivered-To: build@BuildServer1.local
Received: by BuildServer1.local (Postfix, from userid 501)
id A7A94296CBA3; Fri, 2 Mar 2018 10:00:00 +0100 (CET)
From: build@BuildServer1.local (Cron Daemon)
To: build@BuildServer1.local
Subject: Cron <build@BuildServer1> /app/scripts/s3-sync.sh
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=build>
X-Cron-Env: <USER=build>
X-Cron-Env: <HOME=/Users/build>
Message-Id: <20180302090000.A7A94296CBA3@BuildServer1.local>
Date: Fri, 2 Mar 2018 10:00:00 +0100 (CET)
upload: ../../app/logs/debug.log to s3://**my-s3***/app/logs/debug.log
- 371
- 3
- 5
-
1
-
@patrix , I was able to find success cron job also. Updated the answer. – Vineeth Mar 02 '18 at 11:54
-
2This answer told me where to find the information I needed to troubleshoot a crontab job failure. Thanks! – coppereyecat Apr 26 '20 at 23:56
-
Much easier to simply add the following to /etc/syslog.conf :
cron.* /var/log/cron.log
Then tell syslog to reload its configuration:
sudo launchctl kill SIGHUP system/com.apple.syslogd.plist
or to add the following in /etc/asl/com.vix.cron (which makes the log file discoverable for log consumers like the Console.app):
# Cron logging output, from the /System/Library/LaunchDaemons/com.vix.cron.plist launch daemon
> cron.log mode=0640 format=bsd rotate=seq compress file_max=5M all_max=50M
? [= Facility cron] [<= Level info] file cron.log
Tested and working on macOS 11.3
- 103
- 2
- 6
- 251
- 3
- 2
-
5I like this idea - but in 10.10.5, my `/etc/syslog.conf` says `# Note that flat file logs are now configured in /etc/asl.conf`. That file has a different syntax, it's not clear to me how to configure logging in it. – Ken Williams Feb 29 '16 at 18:47
-
@KenWilliams even if it says that, syslog.conf still works, on High Sierra. – Fish Monitor Jan 08 '18 at 04:17
-
2Does not work on 10.15 Catalina -> `/System/Library/LaunchDaemons/com.apple.syslogd.plist: Operation not permitted while System Integrity Protection is engaged` – Cornelius Roemer May 11 '20 at 18:28
-
See https://www.angryox.com/blog/entry/53/how_to_log_cron_jobs_in_os_x_e for the syntax, I put mine into `/etc/asl/com.vix.cron`. – Martijn Pieters Jul 19 '21 at 11:19
-
1I note that it is simply enough to send a HUP signal to the syslogd daemon: `sudo launchctl kill SIGHUP system/com.apple.syslogd`, no need to do a full restart. – Martijn Pieters Jul 19 '21 at 11:41
Turned out when cron was running the job (as me), /usr/local/bin was not in the PATH.
I found this by trial and error and building the job from scratch from a simple things that I knew would work and gradually added things until I found the problem.
About the other suggestions and answers:
For some reason (at least on my machine, which is running a Lion upgraded from SnowLeopard) cron does not use the parameters specified in the plist files that launchd is supposed to read /System/Library/LaunchDaemons/com.vix.cron.plist or maybe cron on Lion does not write anything to stdout or stderr.
By the way I am using http://s3tools.org/s3cmd to sync a folder with an Amazon S3 bucket as a backup (like a primitive DropBox).