Why your cron.daily script is not running

Updated on June 24, 2024
By Pete Freitag

Over the years when setting up linux servers I have run into many different reasons that prevent cron.daily or cron.hourly scripts from executing. Today however, I ran into a whole new reason that I had never encountered before.

I ran into this problem on a Ubuntu Linux server. I placed a script in /etc/cron.daily/my_script.sh but it was not running each day.

I checked all the usual suspects, the reasons I was aware of that cause a cron script to be ignored:

The script had the execute, or x permission. This is probably the most common reason why a cron.daily script will fail to run, you can chmod a+x my_script.sh to fix this.
The script did not depend on certain environment variables being set (for example if you rely on $HOME to be set, you may need to define it yourself). Cron scripts do not have all the same environment variables that you have when you are logged in to a shell, so the script can work when you run it but fail when cron runs it.
The script did not rely on a customized PATH to execute commands. The PATH that cron gives your script will be minimal, and if you have made customizations to it they may not show up. The best way around this is to use the full path to your commands (use the which command to help figure this out).

But my problem was not any of the above. I found that you can execute the run-parts command in a test mode to see which scripts it would call in a directory. You can run it like this (it will not execute any of the scripts, it just outputs which ones it would execute):

run-parts --test /etc/cron.daily

My script was not listed in the output!

Well, that was comforting at least, but why my script omitted from the cron.daily scripts to execute? It turns out you cannot have a file extension on the script, so by renaming the script from my_script.sh to my_script it works!

To be a little bit more precise, the issue is that you can't have a . (dot) in the file name of your cron.daily or cron.weekly or cron.hourly scripts. This issue appears to be specific to certain linux distributions. It occurs on Ubuntu and Debian, but the same script may work fine on RedHat Linux servers.

cron linux unix shell

Why your cron.daily script is not running was first published on January 10, 2018.

If you like reading about cron, linux, unix, or shell then you might also like:

Weekly Security Advisories Email

Advisory Week is a new weekly email containing security advisories published by major software vendors (Adobe, Apple, Microsoft, etc).

Comments

Thanks! In my case, there was two of them not set as executable (chmod +x scriptfile).

by Javier Lobo on 06/13/2019 at 2:56:29 PM UTC

Your post saved my life! or at least my backups. I was setting up backups on a new systems, and decided to copy an existing system. I noticed its backups were dated that same as when I set them up.

The run-parts and extension tips did the trick. One thing., my scheduled backup command starts with '$(which duplicity)'

Is there a way that I can verify it will work when cron runs it?

by ikomrad on 03/01/2020 at 6:17:46 PM UTC

This was ... exactly what I needed, the issue being file extension. Thank you

by Anders Markendahl on 05/07/2020 at 8:25:24 PM UTC

Thanks for sharing this. I never would have guessed that a file extension would prevent a daily cron script from running!

by Tristan on 09/15/2020 at 4:00:02 PM UTC

Thank you for sharing.
I've got a lot of experience work with RH/CentOS, and only have a couple of servers with Debian. Little differences like this one can drive you nuts (sames script on the other servers works fine with the extension).

by Ivan V. on 09/17/2020 at 9:48:22 AM UTC

It's not the extension per se; it's the ".". But I'd never have guessed either.

by Winston on 11/04/2020 at 6:16:57 AM UTC

Many thanks for this post. It really kept me confused why my script runs correctly manually but it won't run automatically with the other cron.daily scripts.

The post is spot on !

by Ali Kalamchi on 01/15/2021 at 10:50:51 AM UTC