If I scp a cron file into /etc/cron.d it doesn't run unless I edit the file and change the command. Then crond seems to pick up the cron file.

How can I make cron reload its cron files in ubuntu 10.04? 'touch'ing the file doesn't work nor does 'restart cron' or 'reload cron'.

My cron file is set to run every minute and logs to a file. Nothing ends up in the log file until I edit the command, and there's no entry for it in /var/log/syslog

I'm stumped.

Here's my cron file saved to /etc/cron.d/runscript (note it ends with a new line)

# Runs the script every minute. This is safe because it will exit with success if it's already running
* * * * * www-data if [ -f /usr/local/bin/thing ]; then exec /usr/bin/php /usr/local/bin/thing mode:prod -a 14 -d >> /var/log/thing/mything.log 2>&1; else echo `date +'[\%D \%T]'` "Thing not deployed. Command not run" >> /var/log/thing/mything.log; fi &
  • 3
    It's good that you included the user to run the job as. I left that out, which was the cause of my troubles. Commented Oct 21, 2014 at 2:18

5 Answers 5


I've just run into this problem and whilst it will not answer your specific case, it may well help other people googling the same problem as this question returns very high in the results.

I had saved a file in /etc/cron.d and it was being ignored. In my case it was because I had given the files an extension.

mytask.cron did not work but I renamed it to mytask and it worked fine.

Any files with extensions are ignored, so make sure your file that you save does not have any extension.

  • 14
    The cron(8) manual page on Debian/Ubuntu documents this fairly clearly these days: "Support for /etc/cron.d is included in the cron daemon itself [...] Files in this directory [...] must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens. This means that they cannot contain any dots." Commented Sep 25, 2015 at 21:48
  • The filename convention of Debian/Ubuntu is not universally implemented/enforced by all cron implementations (do not rely on it to disable any file in /etc/cron.d )
    – JohannesB
    Commented Feb 24, 2022 at 13:36

Check that the file you are copying ends in a \n. Entries in crontabs that don't have a \n at the end generally run into problems. The easiest way to ensure this is to put a blank line after your last entry.

  • 1
    I was just about to edit my question to say that it does end with \n
    – tom
    Commented Sep 7, 2012 at 9:43
  • 1
    Debian/Ubuntu cron warns about this in syslog, since 3.0pl1-110 released in 2010, cf. changelog entry: "Log crontabs missing newline before EOF to syslog. This is only relevant for crontabs not installed via crontab(1), ie. /etc/cron.d/* and /etc/crontab. Closes: #76625" Commented Sep 25, 2015 at 21:51

Just experienced the same problem. It seems like it could be related to the actual scanning/loading of the file.

After running "touch /etc/cron.d/smon" (my cron-file) I got the following message in /var/log/syslog:

Sep 3 10:21:01 vm-nca-s1 cron[994]: (systemsmon) RELOAD (/etc/cron.d/smon)

...and now it works.


There are some notes you should consider while making a file in cron.d directory:

  1. The files in /etc/cron.d must be owned by root.

  2. The files in /etc/cron.d must not be a group or other writable. So the min permission should be 600. (The files in this directory do not need to have x permission but files in other dirs like cron.daily should have x permission because they run by run-parts) NOTE: If group or pthers have write permission, your file will be skipped.

  3. Don't use extension in file name. some file names are considered invalid (check the run-part manual). For example, the file schedule.sh will be skipped. we should rename it to schedule.


I fond that my problem was with semanage policy permissions... So you cant try this:

sudo restorecon --RRvv /etc/cron.d

You must log in to answer this question.

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