76

Here's what I did on Debian Jessie:

  • install cron via apt-get install cron
  • put a backup_crontab file in /etc/cron.d/

However the task is never running.

Here are some outputs:

/# crontab -l
no crontab for root

/# cd /etc/cron.d && ls
backup_crontab

/etc/cron.d# cat backup_crontab
0,15,30,45 * * * * /backup.sh >/dev/null 2>&1

Is there something to do to activate a particular crontab, or to activate the cron "service" in itself?

Jivan
  • 899
  • 6
    What if it's running and failing with an error you don't get to see because you're redirecting all output to /dev/null? :) – tink Jul 16 '16 at 19:33
  • @tink is it possible to append the output to the end of a file instead? – Jivan Jul 16 '16 at 19:34
  • 2
    sure is; 0,15,30,45 * * * * /backup.sh >>/tmp/testing_cron.out 2>&1 – tink Jul 16 '16 at 19:36
  • 2
    @Jivan, just a small note: ls /etc/cron.d is equivalent to cd /etc/cron.d && ls in terms of output. The only difference is the working directory won't change. – Drew Chapin Apr 03 '18 at 19:50

7 Answers7

108

Files in /etc/cron.d need to also list the user that the job is to be run under.

i.e.

0,15,30,45 * * * * root /backup.sh >/dev/null 2>&1

You should also ensure the permissions and owner:group are set correctly (-rw-r--r-- and owned by root:root)

Stephen Harris
  • 44,540
  • Thanks. But still nothing. /etc/init.d/cron status is running and crontab -l still replies no crontab for root – Jivan Jul 16 '16 at 19:28
  • 25
    crontab -l reports on cron entries in /var/spool/cron/crontabs/ - ie the per user crontabs. /etc/cron.d files are system crontabs and not reported by crontab -l. – Stephen Harris Jul 16 '16 at 19:30
  • @StephenHarris didn't know that, okay so I'll wait an hour or so to check if the script has been executed – Jivan Jul 16 '16 at 19:32
  • @clk thanks for pointing that - yes the script is executable – Jivan Jul 16 '16 at 19:32
  • 6
    Actually I mentioned that it was not working but I just realized that it is after having add root in the file - just crontab -l didn't mention it, as you explained why - thanks for your help – Jivan Jul 16 '16 at 19:38
  • 14
    it seems that also the filename has a role. In my case I had added to etc/cron.d a file with a dot in the middle of the name and the job was never executed until I renamed it – pic Apr 24 '17 at 11:57
  • 31
    same problem here, dashes "-" in filename, changing them to underscores "_" solved the problem, jobs ran immediately. – Rob Apr 27 '17 at 06:06
  • 3
    I also had a dash... what the.... why?! Anyway, thanks @Rob – Nikolay Dimitrov May 23 '18 at 04:23
  • 2
    More details here about filename formats etc... https://unix.stackexchange.com/a/417327/28653 – Tony Jun 28 '19 at 06:32
  • THANK YOU @Rob ... and Tony for the link....wow. – BIU Jul 28 '19 at 12:50
  • 1
    In addition, the user that is specified in the 6th column of a cron.d file needs to be valid, i.e. have getent passwd and getent shadow entries. Otherwise, cron may reload the cron.d file nicely, yet always skip the actual invocation altogether, without any notice in the logs. I noticed this thanks to a comment elsewhere on SE, so I'm passing it along. – Josip Rodin Oct 21 '19 at 06:18
  • 1
    In my case it was the file permissions. Changing from 0664 to 0644 fixed the problem. – Aleš Krajník Nov 21 '20 at 19:08
26

Another thing I've observed is that the file in /etc/cron.d cannot have an extension. In my particular case, I had a symbolic link:

# my-job.crontab
* * * * * root echo "my job is running!" >> /tmp/my-job.log

$: ln -sf /home/me/my-job.crontab /etc/cron.d/
# This did not work -> job would not run

$: ln -sf /home/me/my-job.crontab /etc/cron.d/my-job
# This did work -> job ran fine

File name restriction are documented at run-part man page: http://manpages.ubuntu.com/manpages/xenial/man8/run-parts.8.html, one can pass an --regex option to override the file format.

The default cron behavior however stayed without extensions, see comments under: https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/38022

daniel-balosh
  • 3
rodrigo-silveira
  • 461
  • 3
    This is correct on Ubuntu (maybe on all Debian-derived distros). On Amazon Linux (and maybe on all Redhat-derived distros), you can have a dot in the file name. Thank you Unix.SE. – Law29 Mar 14 '19 at 14:05
  • 1
    I just checked a pure Debian, and dots do not work there either. Dashes do work (unlike what a comment above says). – Law29 Mar 14 '19 at 14:34
23

I think you probably just missing a necessary blank line from the end of your cron file. I had the same issue, but after checking everything listed here (user permissions, filename, cron version etc.), I realized that I did not have line break after the last entry in my /etc/cron.d/own_cron and that causes the entire file being ignored.

slac1024
  • 331
5

For Cron from *bian distros (like Raspbian) you need to enable the -l parameter of the Cron daemon. That is advisable to do using /etc/default/cron config file, enabling the EXTRA_OPTS.

phk
  • 5,953
  • 7
  • 42
  • 71
touchwood
  • 51
  • This was downvoted, but it is correct in some cases, although not explained. On Debian-based distros the -l option to the cron daemon authorizes an extended set of file names in the /etc/cron.d directory, so if the file is being silently ignored because there is a dot in it, then either "adding -l" or "removing dot" will correct the problem. – Law29 Mar 14 '19 at 16:35
4

If you're the only user on this computer, you might want to use just crontab -e. You'll be prompted to select an editor the first time you run the command. Then you can add this to it:

0,15,30,45 * * * * /backup.sh >/dev/null 2>&1

If you change to a normal user account, you'll need to use sudo crontab -e to configure the scripts you want scheduled to run as root.

crontab -l only displays the current crontab, once you set one up using crontab -e. If you have a cron file in /etc/cron.d/, it will not be displayed with crontab -l.

You will also need to verify that your script is executable with: chmod +x /backup.sh.

clk
  • 2,146
  • 2
    thanks - in this case the crontab is set in the context of a Dockerfile so I can't really do crontab -e - but it's a useful information anyway – Jivan Jul 16 '16 at 19:35
3

  1. First of all, check the /var/log/syslog file for cron.d errors,

    sudo grep "cron.d" /var/log/syslog |grep -i error

    could be useful to find errors like bad usernames or bad syntax

  2. If you don't have any, check for all cron.d entries into the same file with

    sudo grep "cron.d" /var/log/syslog

Philippe Gachoud
  • 1,609
2

Check your version of cron.

It seems that if you are using Dillon's crond, you don't need the user in a /etc/cron.d entry.

I figured this out after nearly pulling out my remaining hair.

I have a handful of entries that have been dropped in /etc/cron.d by various installs. After some investigation, I found one of them was working. It didn't have the user. So I took the user out of the others. And they began working.

HalosGhost
  • 4,790
James Nelson
  • 21