33

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. – Josip Rodin Sep 25 '15 at 12:02
45

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).

  • 9
    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. – Travis Griggs Oct 23 '13 at 22:42
  • Couldn't you also just change the script's owner to root? – Geremia May 31 '16 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. – harperville Jan 6 '17 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 '17 at 7:32
3

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
  • 6
    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. – Josip Rodin Sep 25 '15 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 '15 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. – Josip Rodin Sep 25 '15 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 '15 at 12:17
  • OK, I guess I no longer read into that because of common confusion between superuser and serverfault and unix SE sites :) – Josip Rodin Sep 25 '15 at 12:38
2

A possible mistake here is how a single line file is created. From Ubuntu Documentation:

...line has five time-and-date fields, followed by a command, followed by a newline character.

For example, this way of the creation doesn't work:

printf "* * * * * /bin/touch /home/me/ding_dong" > /etc/cron.d/ding_dong

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.