Get APLawrence.com by RSS(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Home > Unix Articles > Cron is not working
Printer Friendly Version
Cron is not working
See also Cron, Batch and At.
Let's just get this out of the way first: when someone says cron is not working, it almost always is, and they have just misunderstood something basic. Usually that's not understanding the environment that cron scripts run under or that the machine was physically shut off at the time cron was supposed to do something.
However, for the sake of completeness, we'll run through everything you might check, including the rare case of cron itself not running at all.
You'll find a "cron" script in /etc/init.d on most systems. I say "most" not because I've ever seen it anywhere else, but because it could be started elsewhere. For example, Mac OS X cron is handled by "launchd" (and is not used for anything by default). Ubuntu is going to be changing init soon (see Replacing init with Upstart), and Upstart will eventually replace cron entirely. I expect that soon enough "cron" will be replaced everywhere, if not by Upstart then by something very like it. But that's still the future as I write this, so I'll assume your cron starts from /etc/init.d. Therefore, the very first question is "Did that script run?":
# ls -lut /etc/init.d/cron -rwxr--r-- 1 root root 4250 Dec 16 00:37 /etc/init.d/cron
The "ls -lut" shows the time the file was last "used" - executed or read. This system was booted just prior to that time, so this makes sense. Is cron still running?
# ps -el | grep cron 1 S 0 2862 1 0 76 0 - 454 2 ? 00:00:00 cron
OK so far. Next we'll see if it has looked at its files:
# ls -lut /etc/crontab -rw-r--r-- 1 root root 255 Dec 16 00:37 /etc/crontab
Cron should read /etc/crontab when it starts up, so this matches. What /etc/crontab actually does depends on your system. For example, this is from an older RedHat system:
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 11 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
But a newer Suse system is entirely different:
SHELL=/bin/sh PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin MAILTO=root # # check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly # -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1
The "run-crons" referred to there is a much more complex script that could easily take up an article by itself, so we'll ignore the details of that and just say that it ends up running stuff in /etc/cron.{hourly,daily,weekly,monthly} (though the contents of those directories are much different than the RedHat system)
So the next place we'd look is /etc/cron.daily:
(Suse system) # ls -lut /etc/cron.daily total 36 -rwxr-xr-x 1 root root 2059 Dec 16 00:16 suse.de-backup-rpmdb -rwxr-xr-x 1 root root 566 Dec 16 00:16 suse.de-check-battery -rwxr-xr-x 1 root root 1320 Dec 16 00:16 suse.de-clean-tmp -rwxr-xr-x 1 root root 371 Dec 16 00:16 suse.de-cron-local -rwxr--r-- 1 root root 1196 Dec 16 00:16 suse-do_mandb -rwxr-xr-x 1 root root 1875 Dec 16 00:16 suse.de-backup-rc.config -rwxr-xr-x 1 root root 393 Dec 16 00:15 logrotate -rwxr--r-- 1 root root 948 Dec 16 00:15 suse-clean_catman -rwxr-xr-x 1 root root 2500 Dec 16 00:15 beagle-crawl-system (RedHat) # ls -lut /etc/cron.daily total 44 -rwxr-xr-x 1 root root 193 Dec 16 04:07 tmpwatch -rwxr-xr-x 1 root root 132 Dec 16 04:07 slocate.cron -rwxr-xr-x 1 root root 100 Dec 16 04:07 tetex.cron -rwxr-xr-x 1 root root 104 Dec 16 04:02 rpm -rwxr-xr-x 1 root root 418 Dec 16 04:02 makewhatis.cron -rwxr-xr-x 1 root root 1603 Dec 16 04:02 prelink -rwxr-xr-x 1 root root 180 Dec 16 04:02 logrotate -rwxr-xr-x 1 root root 800 Dec 16 04:02 certwatch -rwxr-xr-x 1 root root 739 Dec 16 04:02 kjunk -rwxr-xr-x 1 root root 135 Dec 16 04:02 00webalizer -rwxr-xr-x 1 root root 276 Dec 16 04:02 0anacron
These both make sense: the Suse run-crons script runs every fifteen minutes, so its first run is approximately fifteen minutes after startup. The RedHat /etc/crontab says to process cron.daily scripts at 4:02 in the morning, and that's what it did. The "0anacron" script ran first, and "tmpwatch" ran last - and it took roughly five minutes to get from "0anacron" to "tmpwatch".
By the way, if we were not powered on at 4:02, that "0anacron" would have made sure the rest of the scripts still ran; see "man anacron". That wouldn't happen immediately though, and that's often a source of confusion.
Cron also looks for crontabs in /var/spool/cron. Again, the RedHat and Suse systems are slightly different; Suse looks in a "tabs" subdirectory, the older RedHat does not. But the concept is the same, and if you have any crontabs there, "ls -lut" should show that cron read them at startup.
So, if all this is true so far, why didn't a particular job you added run? Let's say I put "/root/bin/foo" in a crontab in /var/spool/cron. The foo script looks like this:
# cat /root/bin/foo date > /tmp/this
and the crontab is this:
# crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.XXXXDWuESu installed on Sat Dec 16 01:22:23 2006) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) SHELL=/bin/sh PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin MAILTO=root # # * * * * * /root/bin/foo
The "foo" file should show a new time stamp every minute:
# date;ls -lut /root/bin/foo Sat Dec 16 01:34:41 EST 2006 -rwxr-xr-x 1 root root 17 Dec 16 01:34 /root/bin/foo
If it does, but you aren't getting the expected output, then your script is at fault: see Cron, Batch and At and UNIX Basics: JOB SCHEDULING. If it does not, then your crontab is probably wrong. The Suse man page warns:
In this version of cron, /etc/crontab must not be writable by any user
other than root. No crontab files may be links, or linked to by any
other file. No crontab files may be executable, or be writable by any
user other than their owner.
Another common mistake is having incorrect fields:
# correct for /etc/crontab only * * * * * root /root/bin/foo
If you put that in a /var/spool/cron crontab, your command won't get run because cron instead does what you told it: run a command called "root" and give it the arguments "/root/bin/foo". The /var/log/messages file shows that happening:
Dec 16 01:49:01 suse /usr/sbin/cron[3764]: (root) CMD (root /root/bin/foo) Dec 16 01:50:01 suse /usr/sbin/cron[3768]: (root) CMD (root /root/bin/foo)
If we correct the crontab:
* * * * * /root/bin/foo
Cron notices the change and now everything works:
Dec 16 01:52:01 suse /usr/sbin/cron[2862]: (root) RELOAD (tabs/root) Dec 16 01:53:01 suse /usr/sbin/cron[3785]: (root) CMD (/root/bin/foo) Dec 16 01:54:01 suse /usr/sbin/cron[3788]: (root) CMD (/root/bin/foo)
Of course all of this began with cron starting. If cron fails to start, the "messages" log will probably give you a clue, as might running "/etc/init.d/crond start" manually. If that script never ran, was it supposed to?
# chkconfig --list | grep crond crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
If 3,4, and 5 did not say "on", that would explain a non-starting crond.
If this page was useful to you, please click to help others find it:
Your +1's can help friends, contacts, and others on the web find the best stuff when they search.
Inexpensive and informative Apple related e-books:
Take Control of iCloud
What's New in Word 2004: Advanced
VMware Fusion 3
iPhone OS 3
Permissions in Leopard
More Articles by Anthony Lawrence - Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Wed Apr 25 09:23:51 2007: anonymous
Something that had me stumped for a while is that run-parts (as
commonly used for running hourly, daily, weekly and monthly scripts)
is picky about its filenames. The man page actually says this (on
Debian at least):
"...names must consist entirely of upper and lower case letters,
digits, and hyphens".
Note that . and _ are not included.
/etc/cron.hourly/my_task.sh
use
/etc/cron.hourly/my-task
Hope that helps someone.
Marcus
Wed Apr 25 19:13:48 2007: anonymous
That helped a lot. Thank you! Martin, you're run run-parts tip was key.
-Steve Krzysiak
Fri Apr 27 15:55:30 2007: DaveC
Don't forget to wait for cron to reload your changes after modifying your crontab. Otherwise your new entries scheduled to run in 1 minutes time might not be run when you expected...
Tue Oct 2 00:10:26 2007: anonymous
THANKS!!!
I was debugging for hours my cron scripts and now I see that I have a _ in a filename!!! KILL that guy who did run-parts!!! Can not use a _ in a filename - jesus, that is REALLY braindead!
thanks again for the hint.
Again hours and hours lost by many, many people because of an idiot programmer.
Wed Jan 9 12:21:41 2008: anonymous
STUPID crap ..
Every year i fall into such bullshit.
Probably some completely insane security "feature" to ignore files with a "."
Well, that one reason why people fail to switch to linux. A proper Quality test should reveal that this is no good feature
Thu Mar 27 23:45:30 2008: anonymous
the 2 posts above are posted by 2 biggest idiots
Fri Mar 28 02:21:39 2008: TonyLawrence
Well, maybe just very angry..
Thu May 29 05:32:33 2008: tim
Brilliant, thanks, cron wasn't even started.
Mon Feb 9 12:14:34 2009: VisheshJoshi
Hello Sir,
I have written a script & I want run that script in every one minits.
I set crontab for that, my cron is not working.
Will you plz help me as soon as possible.
Mon Feb 9 12:18:49 2009: TonyLawrence
If you can't figure this problem out from the above article, please see http://aplawrence.com/rightnow.html for assistance.
Sun Jan 24 16:29:37 2010: SerranoPereira
After going through your tutorial I still couldn't figure out why my script wouldn't run by cron. It turned out that cron runs the cron jobs as root and that my script would fail when it was run as root...
Thanks anyway for the tutorial, it has some very good tips in it.
Sun Jan 24 21:25:11 2010: TonyLawrence
It turned out that cron runs the cron jobs as root
No.
Cron runs root's crontab as root - other cron jobs are run as whatever user they belong to.
Tue Jan 26 06:55:29 2010: anonymous
make sure you work with the personal crontab edited with crontab -e or the system crontab. If you use the system crontab then make sure you add the user in the 6th field.
System crontab : * * * * * root /root/bin/foo
Personal contab : * * * * * /root/bin/foo
Tue Jan 26 12:11:16 2010: TonyLawrence
If you use the system crontab then make sure you add the user in the 6th field.
That's Vixie cron. Traditional Unix cron has no such thing.
Wed Mar 3 21:05:01 2010: mat
My cron stopped working all of a sudden one evening and I only came to realise it when I came into work the next day. Reason was that my oracle password had expired! :)
Thu Mar 4 14:22:10 2010: BigDumbDinosaur
http://bcstechnology.net
My cron stopped working all of a sudden one evening and I only came to realise it when I came into work the next day. Reason was that my oracle password had expired!
Not sure how an Oracle password would stop cron. cron is an operating system tool that is started during boot time, and has nothing to do with Oracle. Perhaps what really happened is you scheduled a cron job that uses Oracle and it wouldn't run due to an expired password.
Thu Mar 4 14:24:37 2010: TonyLawrence
Perhaps what really happened is you scheduled a cron job that uses Oracle and it wouldn't run due to an expired password.
Yes, that's what I assumed he meant also.
Fri Apr 9 08:34:15 2010: anonymous
thank you very much ka ^^
Tue May 4 18:27:54 2010: MattUgray
http://ugray.be
I found this page when trying to figure out why my cron job wasn't running, but wasn't able to get the answer here. It turned out that it was because my script was in a directory I added to PATH in /etc/profile, which only affects Bourne compatible shells, and importantly, not commends executed by cron. So my tip: use full paths for your cron jobs.
Related: http://aplawrence.com/Opinion/religion.html
Tue May 4 20:08:15 2010: TonyLawrence
Not exactly - See http://aplawrence.com/SCOFAQ/FAQ_scotec6cronjob.html
Wed Aug 11 14:59:29 2010: anonymous
I added a cron job into the crontab to execute every minute as follows:
(as root) crontab -e
*/1 * * * * /users/myaccount/scripts/test.sh
Then I monitor the log file as follows:
tail -f /var/log/cron
Aug 11 10:30:01 localhost crond[15611]: root CMD (/users/myaccount/scripts/test.sh )
Aug 11 10:31:01 localhost crond[15618]: root CMD (/users/myaccount/scripts/test.sh )
...
My test.sh script works when executed manually is as follows:
#!/bin/bash
echo hello > test.log
When I run this manually, it creates the test.log file and it contains "hello"
To test the cron job, I delete the file test.log and waited for the cron job to run. The logs show that it ran but no test.log file
Any ideas? Thanks
Wed Aug 11 15:16:53 2010: TonyLawrence
Change your script to first cd to where you want the file created.
Mon Aug 23 15:04:46 2010: anonymous
Or in my case - last night I needed to reboot. When the system came back up crond did not start - why? Who know - it's a ^!@$^# computer. So as su I did ./crontd restart. It stopped, it started and life is good. And this isn't the first time it's happened to me. WAG 1% of the time cron just doesn't run. ps grep cron shows it's there. (brain dead)
cal
Fri Sep 24 09:31:53 2010: solunic
http://www.solunic.at
Thanks so much!
My problem was, like some others here, the run-parts. My scripts had the .sh extension and therefore they were not executed.
Sun Feb 27 17:32:40 2011: anonymous
The note about not to include "." or "_" in cron file names was the key to my problem. Thanks!
Tue Apr 5 14:11:58 2011: Martijn
http://www.freeminded.org
Great article, good troubleshooting. In the end, I found out my problem was that I had a period in the filename. On Ubuntu this is in the manpage but it was not the first think I'd think of.
Wed Jul 6 09:14:26 2011: kaore
http://cibul.net
I had some trouble setting up cron to work with a test script, the solution for me was to copy the SHELL and PATH lines in /etc/crontab and paste them at the beginning of my schedule file.
In my case, these values were:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Wed Jul 6 09:33:04 2011: TonyLawrence
Yes, that's a common problem. Cron's execution environment is not the same as yours, so if you have specific paths or other environment variables needed, you have to set them in your script. You probably didn't need the SHELL line, though.
Wed Aug 24 21:51:06 2011: anonymous
#19 1 * * * bdhlnx76 /var/opt/sterlingPROD/sterling/Foundation/bin/triggeragent.sh SHIPMENTPRG
this is the cron tab we are using to trigger some agent daily once.
But it is triggering multiple times
how I debug it please revert back with solution as soon as possible
Wed Aug 24 22:07:10 2011: TonyLawrence
OSS642 fixed that issue a long, long time ago.
Fri Sep 30 12:21:40 2011: anonymous
Where can i find /etc/crontab in sco 5.0.7
Fri Sep 30 12:33:00 2011: PeterV
When i type
#crontab -e -u root
i receive an empty vi page at the end
/tmp/_edit10109
my cron still run
Fri Sep 30 12:33:58 2011: TonyLawrence
You won't find /etc/crontab. This is traditional Unix cron, not Vixie cron.
Cron jobs are in /var/spool/cron/crontabs by user name. Don't edit those files; cron won't look at them again until it restarts.
See http://aplawrence.com/Unixart/cron.html and http://aplawrence.com/BDD/bbcronbasics.html
Fri Sep 30 12:36:02 2011: TonyLawrence
PeterV: I have no idea what you are trying to say. Read the articles noted in my comment just above and reformulate your question.
Thu Nov 17 08:20:14 2011: balajiTP
while i run cron my crontab is running. But in log file it showing following error......
Error: Kitchen cant continue,because job cant be loaded
Thu Nov 17 09:20:27 2011: TonyLawrence
That's not a cron error. That's an error from Kitchen. Check your docs: http://jira.pentaho.com/browse/PDI-499
Thu Dec 22 12:28:12 2011: RobertReiz
http://robert-reiz.com
For me cron is just not working. I am adding something like that to my crontab.
1 * * * * /bin/bash -l -c '/opt/out/out.sh'
And it is just not running. I tried it already with different variations. And I googled for hours. And since years I always have problems with cron. It is a peace of crap.
To make a shitty shell script running as a cron job you have to read a whole book and be a Linux Super Guru. It is just far to complicated. It is not easy enough.
I don't like complex software. I like easy to use software. And cron isn't easy!
It is always a day spending research project to make cron job running.
Buy a cheap Linux server and spend days with configuration issues.
Why it is not so easy like in Mac OS X?
Thu Dec 22 12:35:44 2011: TonyLawrence
Perhaps Linux is not for you?
All I can tell you is that your answer is somewhere on your page. There is always a reason, it isn't "shitty software" and it will work.
I don't want to make light of your anger. I understand that these things can be confusing.
Thu Dec 22 12:37:28 2011: TonyLawrence
By the way, when I say "somewhere" on this page, that includes the links to other pages. Your actual issue is more likely at the pages about cron scripts rather than here.
Tue Dec 27 09:07:30 2011: RobertReiz
http://robert-reiz.com
Hey. Thank you for your answer. I solved my problem now in another way.
As a student I was always sitting their for days to make it work. Because I thought It is my fault if its not working. Today I have a lot of experience. I worked as couch and trainer. I spoked with a lot of Software Developers and worked on a lot of projects. And today I have a different view to Software. I think the most Software-Projects are far to complicated. Software Developers are thinking to complicated. They should learn to think simple! And They should read "Clean Code" and "The pragmatic programmer".
I extended my program now with 3 lines of code. It is running now as daemon and I am not depending anymore on crontab.
Tue Dec 27 13:26:56 2011: TonyLawrence
I'm happy that you solved your problem, but, no matter what you think, cron was unlikely to have been the issue.
Fri Jan 13 20:49:19 2012: Stas
On our RHEL 5.5 system the jobs were not running from user's cron. Root cron was OK. The fix ofr our problem was as follows:
vi etc/pam.d/crond
add below line
account required pam_access.so accessfile=/etc/security/access-cron.conf
touch /etc/security/access-cron.conf
Add this line /etc/security/access.conf as second last line:
+ : oracle : cron crond
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar