23

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?

  • 4
    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
  • 1
    sure is; 0,15,30,45 * * * * /backup.sh >>/tmp/testing_cron.out 2>&1 – tink Jul 16 '16 at 19:36
  • @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 3 '18 at 19:50
43

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)

  • 15
    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
  • 5
    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
  • 8
    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
  • 17
    same problem here, dashes "-" in filename, changing them to underscores "_" solved the problem, jobs ran immediately. – Rob Apr 27 '17 at 6:06
  • 1
    I also had a dash... what the.... why?! Anyway, thanks @Rob – Nikolay Dimitrov May 23 '18 at 4:23
4
+100

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

  • Man, you saved my day! – elboletaire Oct 1 '18 at 12:19
  • 1
    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 at 14:05
  • 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 at 14:34
3

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.

2

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.

  • 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
1

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.

1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.