Where is my logfile of crontab?

Question

No /var/log/cron, no /var/log/cron.log on my Debian 7. Where is my logfile of crontab?

ls /var/log/cron*
ls: cannot access /var/log/cron*: No such file or directory

score 20 · Accepted Answer · edited Jun 14 '23 at 13:38

20

I think on debian cron writes logs in /var/log/syslog.
If your system depends on rsyslogor syslogd you can check and uncomment either in /etc/rsyslog.conf or /etc/syslog.conf for line:

# cron.* /var/log/cron.log

and then restart services.

If your system depends on systemd for example you can check with following command:

journalctl _COMM=cron

or

journalctl _COMM=cron --since="date" --until="date"

For date format you can check journalctl.

edited Jun 14 '23 at 13:38

AdminBee

22,803

answered Jun 26 '15 at 08:35

taliezin

9,275

no /etc/rsyslog.con and /etc/syslog.conf in my debian7. – showkey Jun 26 '15 at 11:54
fot the first file it is a typo should be /etc/rsyslog.conf if you are not with systemd. – taliezin Jun 26 '15 at 12:14
2

what about sudo journalctl --since yesterday -u cron.service? What is _COMM? – dashesy Jan 11 '17 at 00:26
1

@dashesy _COMM filters log entries by the name of the log-emitting executable. However, at least on some systems that executable is actually named crond. Thus, you have to use _COMM=crond on those. With -u cron.service (or rather -u crond.service or the shorter -u crond) you only get a subset of job execution logs - at least on some systems. For example, on Fedora 38 I don't see the logs of non-root cron jobs and even the root ones are incomplete when filtering by -u crond.service. – maxschlepzig Jul 01 '23 at 13:00

score 5 · Answer 2 · answered Sep 29 '19 at 14:59

Since this is not tagged debian and appears in fedora searches as well, here is how to check for recent (systemd-based) fedora:

sudo systemctl status crond

Typical output

● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-09-29 16:09:21 CEST; 47min ago
 Main PID: 1167 (crond)
    Tasks: 1
   Memory: 2.8M
      CPU: 948ms
   CGroup: /system.slice/crond.service
           └─1167 /usr/sbin/crond -n

Sep 29 16:09:21 ncelrnd0216 systemd[1]: Started Command Scheduler.
Sep 29 16:09:21 ncelrnd0216 crond[1167]: (CRON) STARTUP (1.5.4)
Sep 29 16:09:21 ncelrnd0216 crond[1167]: (CRON) INFO (Syslog will be used instead of sendmail.)
Sep 29 16:09:21 ncelrnd0216 crond[1167]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 31% if used.)
Sep 29 16:09:21 ncelrnd0216 crond[1167]: (CRON) INFO (running with inotify support)

and all the logs with

journalctl --unit crond -n all

On Fedora 38 such a log is incomplete, i.e. job execution logs from non-root users is excluded and many CMEND lines of root jobs are missing. Whereas filtering by _COMM=crond includes them. See also my answer. — maxschlepzig, Jul 01 '23 at 13:03

score 4 · Answer 3 · edited Jun 14 '23 at 13:36

By default the output from crontab jobs are sent to the local email address of the owning user. for example: The crontab output for aUser on host www.aDomain.com would be sent to aUser@www.aDomain.com. The system uses its default mailer to accomplish the task.

You can divert this output to an alternate email address by adding a MAILTO statement within the crontab file. For example:

# Mail any output to myuser@gmail.com, no matter whose crontab this is
MAILTO=myuser@gmail.com
# Run the following command ten minutes after midnight, every day
10 0 * * *       $HOME/bin/aJob.sh

Be careful when using an external email address to receive crontab logs. Frequently sent messages may get caught in a spam filter. You would then have to mark the messages as Not Spam for services like Yahoo, HotMail, or Gmail.

An alternate solution would be to redirect the output of your crontab commands to a file of your choice. In the example below the stdout and stderr output is sent to /tmp/aJob.log. This method eliminates the possibility of an email message being sent.

# Run the following command ten minutes after midnight, every day
10 0 * * *       $HOME/bin/aJob.sh >> /tmp/aJob.log 2>&1

Another alternative is to send stderr logs to email and stdout logs to a file. In this case you get alerted by email when your crontab commands generate unexpected error messages. The difference with the previous example is that 2>&1 is removed to allow stderr output to go to the console and therefore to email.

# Mail any output to myuser@gmail.com, no matter whose crontab this is
MAILTO=myuser@gmail.com    
# Run the following command ten minutes after midnight, every day
10 0 * * *       $HOME/bin/aJob.sh >> /tmp/aJob.log

Read more crontab tables and crontab command

OP is likely referring to the logging of the Cron daemon itself, whereas you are referring to the stdout/stderr handling of cron jobs. When a cron job time specification matches, a Cron daemon logs its job execution, i.e. even when it was successful. For example, cronie logs CMD/CMDEND including full command lines and user name. By comparing matching CMD/CMDEND lines you can compute the job's run time. — maxschlepzig, Jul 01 '23 at 13:12
I think in classic cron daemons there actually was no idea of and no need for logging the operation of the cron daemon itself, as anything it did was to start a command on a time based schedule. So for diagnostics of a working cron daemon it is best to simply schedule a job and check it's output in some very near future. That way you also train to modify the crontab. But in the end you are right: The question is about the cron daemon itself. I just never had a use for that. — ikrabbe, Aug 17 '23 at 08:38

score 1 · Answer 4 · answered Jun 22 '20 at 08:16

1

Check MAILTO's inbox: /var/spool/mail/root. The cron job's execution log will remain there.

answered Jun 22 '20 at 08:16

Haoyuan Ge

121

score 1 · Answer 5 · edited Jun 16 '23 at 15:49

1

2020: Google brought me for something similar.

With distros that are using systemd, there is no more /var/log/messages or /var/log/cron.

With systemd, the journald daemon handles logging.

To see if cron is running your scripts and to follow the log, use;

journalctl -u cron.service -f

edited Jun 16 '23 at 15:49

Benjamin Loison

178

answered Jul 02 '20 at 15:01

MarcoZen

191

And in case you are using another cron tool, such as cronie in my case, then the right command is "journalctl -u cronie.service -f". Remove "-f" (follow) to see if you have received any logs until now. – Ioannis Koumarelas Jun 05 '22 at 21:46

score 0 · Answer 6 · edited Feb 17 '21 at 18:32

0

Create a cron file in /var/log and restart the syslog service:

# touch /var/log/cron
# systemctl restart rsyslog

then check for logs.

edited Feb 17 '21 at 18:32

Jeff Schaller

67,283
35
116
255

answered Feb 17 '21 at 07:28

Anudeep Sharma

1

score 0 · Answer 7 · answered Jul 01 '23 at 12:50

On a journald enabled Linux system you can view the cron job execution logs like this:

# journalctl SYSLOG_IDENTIFIER=CROND

Example output:

[..]
Jul 01 06:23:02 example.org CROND[143073]: (backupuser) CMD (/usr/local/bin/backup.sh)
Jul 01 06:24:36 goedel.lru.li CROND[143045]: (restic) CMDEND (/usr/local/bin/backup.sh)
[..]

Alternatively, you can filter on the executable name of your cron daemon, which is less to type (unless your cron daemon's executable is named differently):

journalctl _COMM=crond

NB: journalctl -u crond also includes some job logs, but at least on some systems it's incomplete, i.e. non-root user jobs are excluded and many CMDEND lines are missing. (e.g. I'm observing this with systemd-253.5-1.fc38.x86_64)

You can combine the above filters with other predicates, e.g. to to just list the logs of a certain user after a certain point in time:

journalctl --since '2023-07-01 08:23' SYSLOG_IDENTIFIER=CROND _AUDIT_LOGINUID=666

Or to jump to the end of the log:

journalctl SYSLOG_IDENTIFIER=CROND -e

Where is my logfile of crontab?

7 Answers7

Linked