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

/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?

  • 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, 2016 at 19:33
  • @tink is it possible to append the output to the end of a file instead?
    – Jivan
    Jul 16, 2016 at 19:34
  • 2
    sure is; 0,15,30,45 * * * * /backup.sh >>/tmp/testing_cron.out 2>&1
    – tink
    Jul 16, 2016 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. Apr 3, 2018 at 19:50

7 Answers 7


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


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)

  • 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. Jul 16, 2016 at 19:30
  • 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, 2016 at 19:38
  • 15
    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, 2017 at 11:57
  • 32
    same problem here, dashes "-" in filename, changing them to underscores "_" solved the problem, jobs ran immediately.
    – Rob
    Apr 27, 2017 at 6:06
  • 4
    I also had a dash... what the.... why?! Anyway, thanks @Rob May 23, 2018 at 4:23

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

  • 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, 2019 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, 2019 at 14:34

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.


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.

  • 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, 2019 at 16:35

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.

  • 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, 2016 at 19:35
  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

  • on RHEL7, it can be found on log file /var/log/cron
    – Jacobski
    Jan 10, 2023 at 21:42

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.


You must log in to answer this question.

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