19

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

7 Answers 7

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.

4
  • no /etc/rsyslog.con and /etc/syslog.conf in my debian7.
    – showkey
    Jun 26, 2015 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, 2015 at 12:14
  • 2
    what about sudo journalctl --since yesterday -u cron.service? What is _COMM?
    – dashesy
    Jan 11, 2017 at 0: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. Jul 1, 2023 at 13:00
5

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
1
  • 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. Jul 1, 2023 at 13:03
4

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 [email protected]. 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 [email protected], no matter whose crontab this is
[email protected]
# 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 [email protected], no matter whose crontab this is
[email protected]    
# 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

2
  • 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. Jul 1, 2023 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, 2023 at 8:38
1

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

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
1
  • 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. Jun 5, 2022 at 21:46
0

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

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

then check for logs.

0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .