I have thrown a bunch of darts trying to get a python script of mine to execute every minute. So I thought I'd simplify it to just do the "simplest thing that could could possibly work" once per minute (I'm running debian/testing).

I created a single line file in /etc/cron.d/perminute:

* * * * * /bin/touch /home/me/ding_dong

It's owned by root, and executable (not sure if either of those matter). And then I did:

sudo service cron reload

And then sit back and start running ls -ltr again and again in my home directory (/home/me). But my ding_dong file never shows up. I know if I do a sudo /bin/touch /home/me/ding_dong, it shows up right away.

Obviously missing something stupid here.

  • 3
    Reloading the cron daemon service in order to apply a change in cron.d is usually unnecessary because it rescans the directory for new and updated files every minute anyway. Sep 25, 2015 at 12:02

2 Answers 2


When adding a cron configuration in /etc/cron.d/ or in /etc/crontab you have to add the username in which context the command should run, in your example

* * * * * root /bin/touch /home/me/ding_dong

And just a hint from me: you don't have to start running ls -ltr again and again, just use watch -n 5 "ls -ltr" and it will run the command every 5 seconds (or any other value by replacing 5 with what you want).

  • 10
    This got me going in the correct direction. It was a headsmack moment. I fixed it, and yet it still didn't work. After reading man cron a little slower, and paying special attention to the DEBIAN specific sections, I noticed that the files must NOT be group or other writable. Which I had enabled in my frustration at one point. Oct 23, 2013 at 22:42
  • Couldn't you also just change the script's owner to root?
    – Geremia
    May 31, 2016 at 16:05
  • This specific line helped me. From man cron: Additionally, in Debian, cron reads the files in the /etc/cron.d directory. cron treats the files in /etc/cron.d as in the same way as the /etc/crontab file (they follow the special format of that file, i.e. they include the user field). However, they are independent of /etc/crontab: they do not, for example, inherit environment variable settings from it. This change is specific to Debian see the note under DEBIAN SPECIFIC below. Jan 6, 2017 at 14:45
  • man 8 cron (on Debian) also says that files in /etc/cron.d/ may only contain alphanumeric characters, '-' and '_'. Specifically, no dots.
    – mpartel
    May 17, 2017 at 7:32

To create a new cron job, you should run crontab -e as the user you want running the job. Then add the relevant line in the editor window that appears:

* * * * * /bin/touch /home/me/ding_dong

The way you are doing it requires a different format and is really not a good idea anyway. Crontabs in /etc/cron.d have a slightly different format, they require a user name to be run under. For example:

* * * * * USERNAME /bin/touch /home/me/ding_dong

A good trick (as suggested by @VogonPoetLaureate) is to capture the standard error of your cron jobs which can help debug them. For example:

* * * * * /bin/touch /home/me/ding_dong 2>/tmp/error
  • 7
    There's absolutely no reason to say that cron.d is "not a good idea". The cron daemon will mail cron.d stderr output to the username just fine, and if you want to redirect it to another e-mail address, the MAILTO variable is available. Sep 25, 2015 at 12:01
  • @JosipRodin it's not a good idea for things not run by root and which are set up by you. It makes sense for a sysadmin on a multiuser system but on your own machine, it is simpler to have everything in your own crontab so there's only one place to check and crontab -l lists all your cron jobs.
    – terdon
    Sep 25, 2015 at 12:10
  • That assumes it's really just a personal cron job, which the OP didn't really clarify - generally, there's numerous applications for unprivileged user cron jobs set up via cron.d, such as keeping them all in one place despite the fact you have nicely sequestered service users, automated deployment is easier, etc. Sep 25, 2015 at 12:14
  • @JosipRodin absolutely. I assumed a personal system because i) enterprise systems are off topic here and ii) the question suggested a non-expert user.
    – terdon
    Sep 25, 2015 at 12:17
  • OK, I guess I no longer read into that because of common confusion between superuser and serverfault and unix SE sites :) Sep 25, 2015 at 12:38

You must log in to answer this question.

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