Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 4 down vote favorite
1

I've noticed jobs in /etc/cron.d/ not running, the odd thing is that X amount will run but then the rest won't.

I've read comments from people about not using a '.' in the filenames, none of my files have any dots in them.

I've also read that you should always place a blank line at the end of each file, but that didn't seem to make any difference.

In the end I stripped out ALL comments from every single file in /etc/cron.d/, this made all jobs run correctly.

Cron was not putting any errors messages in to /var/log/syslog or /var/log/messages, there is no /var/log/cron(d).log

Has anyone encountered anything like this before? If so is there a solution for commenting without it causing problems?

share|improve this question
Without seeing any examples it's hard to guess, but if I had to one guess would be that you had DOS/Windows line endings in the file (CR/LF) instead of Unix line endings (LF). What about the files in /etc/cron.{hourly,daily,weekly,monthly} and /var/spool/cron/crontabs/root? – Dennis Williamson Aug 31 '10 at 13:47
+1 . Can you identify what the comment line was that caused the failure? It would be interesting to post that if possible. Also did these files run when called directly from the shell? I cannot see that a comment would cause a cron job to fail. Also not using '.' in file names and use of blank lines don't cause issues in my experience. – Richard Holloway Aug 31 '10 at 13:52
Following on from Dennis comment. If you get 'Bad interpreter' errors when trying to run jobs this is usually caused by Windows line endings. – Richard Holloway Aug 31 '10 at 13:53

2 Answers

up vote 1 down vote

Use # at the beginning of the line to comment.

Crontabs are not supposed to have a blank line at the end - maybe they accept it in recent releases(?) but for a long time is was causing problem.

Usually a mail is sent to the crontab owner with the output / problems. If the crontab belongs to root, you should open its mailbox.

share|improve this answer
up vote 0 down vote

Quick update to the above comments

@Dennis - They all ran without any issues.

@Richard - All fines contained Unix line endings, if any of my developers used Windows line endings they would feel my ban hammer instantly.

There was no output or problems because the cron files simply did not run. Checking mailboxes was one of my first ideas.

Adding a simple - echo "file ran" > /root/cron-has-worked - to a job confirmed that it was not working, also sitting and watching /var/log/syslog in one shell and top in another confirmed cron jobs not running.

Thank you for the comment about using # but I do know how to comment cron files. =P

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.