I have a Debian GNU/Linux 4.0 box (that cannot be upgraded) running 24x7. It has several jobs in /etc/cron.daily, including our backup scripts. I noticed several weeks ago that the backup script was not running with any regularity.

This morning, I ran the cron directory manually (nice run-parts --report /etc/cron.daily) which is seen in both /etc/anacrontab and /etc/crontab. I got an email for logwatch, but not for any of the other jobs. Our backup scripts, specifically, have a large amount of output, and take a few hours. I have tried rearranging the jobs in /etc/cron.daily, with no effect, and I've recently removed anacron, since this box should "never" experience downtime.

Running any of the jobs individually seems to work fine. I've just added the backup script to /etc/crontab manually to see if it runs properly.

Does anyone have other suggestions?

6 Answers 6


The problem turns out to be that Debian does not allow '.' in the filename of a cron job stored in /etc/cron.(d|daily|weekly|monthly). Remove the '.', and the job runs fine.

  • Actually... I'll have to keep this in mind if there are cron jobs in cron.daily I want to temporarily disable. It does make sense, in a twisted sort of way: UNIX and its clones mark files as hidden by putting a . at the start of their filename.
    – Powerlord
    Aug 18, 2010 at 18:46
  • 4
    @R. Bemrose FYI, for debian, the . doesn't have to be at the beginning. It can be anywhere in the name of the script. Sep 1, 2010 at 14:25
  • 1
    Ugh, this has been bugging me for a week. Thanks :)
    – Ben Hughes
    Nov 19, 2012 at 13:03

Are the logs for cron showing any errors, or that they're running at the specified times?

What happens if you watch the processes run at the times they're supposed to be running (i.e., if they are scheduled to run at 4:00PM what does the system look like in the process list and logs at 4:01?

Silly question, but you said you get emails from logwatch but not for any other jobs. Did you double check that the jobs are actually failing, and not that there's a communication issue with emails notifying you of completed jobs?

Are the jobs running as the proper user context, with permissions to do things needed? These are failing only sometimes but not others?

Can you find anything happening during those times that they fail but not other times (you said this is a no-downtime system...is it doing something where the scripts are overlapping so they can't complete? or there are processes that would block them?)

Is there anything configured on the system that kills processes at a certain load level? Watchdog timers, etc. may kill a process if the load is too great or processor/ram quota goes too high, etc. or the system becomes unresponsive. Another reason to see if someone can keep an eye on it through a ssh session at a point when the server should be running the job.

  • 1
    +1 Nice checklist :-).
    – sleske
    Jan 5, 2010 at 16:33
  • First thing would be to have a look at cron's log (usually /var/log/cron, /var/log/messages or /var/log/syslog ). There should be an entry every time cron starts a job (something like "/usr/sbin/cron[123]: (root) CMD /my/command ..."). Check if that is present; that will tell you if cron even tries to run the job.
    – sleske
    Jan 5, 2010 at 16:35

Bart nailed about everything I would look for, except maybe disk space. When the jobs all run together to they run out of space? Is there something else happening at that time that might put a big, temp load on the drive space?

Another thing you might try, if you can, is to run them at a different time. Either all at once, say 5:00, or individually, 4:00 / 4:30 / 5:00 / 5:30 / etc...

  • I think the final "solution" was that there is a problem with hidden dot (.) files on Debian.
    – Richard
    Jan 12, 2010 at 23:54
  • Not hidden files, just filenames with a . in them, eg "backup.sh" Aug 19, 2010 at 1:32

another thing could be the environment. have the scripts already successfully run via cron? the cron environment can be different to your testing environment (PATH, ...). is it possible to add logging to your backup scripts with logger or echo commands?


I also had the same problem with '.' in script names. Removing any '.' in the script name resolved my problem (even the extension ".sh"!)


The --lsbsysinit or --regex options to run-parts allow you to change which filenames are considered valid.

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.