Instead of actually accomplishing things the past week I've been trying to debug... Drupal, my install, MySQL. I literally spend ALL day working (not for pay) on this.
Cron will not run. It fails indefinitely.
I finally got one install (I duplicated my site on another server, with the same error) to work by uninstalling getID module. So I go to the other install and do the same thing, nothing.
I back track all the steps up to that and nothing. I've done this back and forth, uninstalling modules, reinstalling, trying to narrow down the problem and with all the countless tests I have not reproduced anything that works so that I know how to avoid the problem.
Anyways, I am about 2 days away from quitting Drupal altogether. I mean, I am one guy, not making any money doing this, just trying to make some simple websites and it never fails that every few days some wrench gets thrown at me with no helpful error messages. But this one has been going on for weeks and no one seems to have any answer.
I WANT to use Drupal, but if something goes wrong it is so hard (perhaps impossible in my case) to correct. So I'm left with a website I've put so many hours into that I can't even work with anymore.
If anyone is feeling generous, I am free Sat morning until noon and Sat afternoon from 4-6 if anyone wants to take a look at this. I've put the past year of my life into learning Drupal, I hope I can continue my learning. But if I can't fix this, there's really no point.

Comments
Acquia Drupal
I am new at Drupal so I may not comprehend the full complexity of your issue, but I recall that running cron was one of the first puzzles I ran into after installing Drupal. I still don't know exactly what it does, but Acquia Drupal has a separate admin menu at top of screen that makes running cron a snap. I suspect you know how to run cron and have other issues so please excuse my naivitee. If you haven't tried Acquia Drupal, you may find that it adds a few belts and suspenders that might be helpful.
www.acquia.com
What are your specs?
What are your specs?
What host are you using?
Are you using Drupal 6.14?
MySQL Version?
PHP Version?
Are you using poormanscron or the real deal?
answers
I use Hostmonster and HotDrupal. I copied site from HM to HD and had same problem, which is good.
Using 6.14 yes.
MySQL 5.0.81
PHP 5.2.9
Apache version 2.2.13 (Unix)
I either use Cron Jobs in CP or run manually from /admin/reports/status
I feel your pain!
Hey Branjawn,
OH man! I spent a lot of time with Drupal. I thought I was going to go INSANE. But then I realized that switching to another CMS wouldn't help because I still had to deal with stuff like cron and MySQL! But through all the problems, I've always liked Drupal. And I never really played with cron. I just would run cron manually within the drupal admin part. It was months until I finally got around to setting up cron with dreamhost. And I did that wrong, but tried it again and got it correct. I did that within Dreamhosts panel. Currently, I don't have the brains to command line cron...But I'll get there some day.
Another thing that drove me crazy was that I had 2 separate Drupal installs. 1 for the fun of it, and the other was a test site for a missions organization. Well, the thing that drove crazy is that I was always having problems with trying to get stuff to work correctly with the missions organization web site, YET my personal, play-around site worked fine.
What other issues are you having other than cron? Who do you host with?
Answers
"And I never really played with cron. I just would run cron manually within the drupal admin part."
I don't play with it either, it just stopped working. I went to admin/reports/status and it showed Cron last run 18 hours ago (this was on Wednesday) when it's supposed to run every 45 minutes.
Update
So I finally got wise and actually hand wrote each step I took.
Starting with a cron that would not run, I started unchecking module, sometimes uninstalling, and sometimes even deleting the folder from sites/all/modules to be sure it was gone.
I eventually got Cron to run. But I still don't know what caused it. And to me that is no solution at all because inevitably it will fail again and I don't want to spend another week debugging, I want to know what caused it so I can a) fix it quickly b) avoid it altogether.
Well, I did the steps in reverse and could not cause a cron fail. It's frustrating that undoing what fixed it won't break it. Which leads me to believe some unseen unknown (to me) process is behind all this.
So, today I will try and break it again, documenting every action I make, and then try and undo those to see where it fixes. It may take a while, but I hope I can eventually narrow it down to a module or action (e.g. refresh feed).
Any insights appreciated.
Be sure to keep an eye on
Be sure to keep an eye on your server's error logs, too.
What command are you running with CRON?
For a long time I was running a command like "php /public_html/cron.php" but this stopped working and my hosting company could not explain why. Now I use "curl http://somesite.com/cron.php". This has always worked for me.
Dave
I've been using Drupal for
I've been using Drupal for about 2 years. I came from using Xoops and Joomla. I won't explain or knock the other CMS. Straight talk, if you stay with CMS the Drupal is the best way for large sites, SEO and all the things associated with competent sites.
The automatic updater tool is awesome. You can find instantly what modules to upgrade with direct links to them.
You unzip them and install. This is great because security vulnerabilities can be dealt with post haste.
Some modules are key to good success with Drupal, and maybe included with forthcoming releases.
You still have to do alot of work to get a good install. There are about 4,000 modules that you can use. Some are really worth their salt, and others... just so so.
The support for modules is very good. You should pre-evaluate moduels by looking through the open and closed issues before you download a module. If you read the issues and it looks like there are a lot of non-responses from the dev you might want to think twice before install that module.
Stay away from CODING. You want to make your life miserable start messing with the code, when you don't have a thorough understanding of Drupal. Maybe a few CSS or theme changes is not biggy, but you start changing the code in modules you can corrupt everything... and it won't make sense.
Remember, when you start changing code the module developer can release a security patch or upgrade a couple days later. Then, if you upgrade you will have to redo your coding. Modules are constantly being upgraded it is best practice to use developer version of all modules. If you do make code changes make careful notes and put a readme in the module directory on the server so you can follow up properly.
Always read all you can find on a module before you install it. Make sure you understand what it does and what is required for proper install. If you don't fully understand make an open issue and post for the developer to explain. You'll make your life alot easier.
Drupal is a dream when you get a handle on using it. I currently have 14 sites under construction and many others being administered by site owners. I only make module updates for sites once they are complete. I do restrict specific areas of the sites, if the owner wants admin oversight. This way I always have happy site owners, the sites are very secure and work.
Regardless of what site owners want, if I am not satisfied with any module or theme I will refuse to apply it to a site. The bitterness from troublesome modules or themes will destroy site owner and site user... goodwill.
Good luck
chopping wood
I'm still hacking away at this...
Cron still broke. (broke = 'Cron run failed.')
Have you tried searching the
Have you tried searching the forums?
http://drupal.org/search/apachesolr_search/%22Cron%20run%20failed%22
Yeah, I've scoured the
Yeah, I've scoured the internet looking for an answer. There are so many reasons why cron would fail. that's one of my complaints, Drupal (nor my hosting provider) give any meaningful information as to why it is failing. No clues. No reason. Just a "Cron run failed" msg.
This is a common complaint
This is a common complaint when cron starts misbehaving. It doesn't output anything useful for tracking down the cause. Poormanscron does a better job of logging overall. If you want to get together one evening this week and see if we can work out the culprit I'm happy to take a shot at troubleshooting this.
For sure. I worked on this
For sure. I worked on this yesterday and will continue to today. Will tag end of this thread with updated info.
Why don't you try poormans
Why don't you try poormans cron module.
Then, if it doesn't work make an issue on the developers open issues.
Also, I have had modules that gave me issues.
One thing I always do.. I upload and then install each module individually. Then, I run status report afterward.
This will usually turn up problems with modules.
I have frequently had to complete remove modules from the server folders. I also frequently run a test of Mysql after I remove a module that was previously installed.
I have in the past had cron problems that were actually hosting support issues, not Drupal.
I tried Poormans last week,
I tried Poormans last week, re enabled today. It triggers error msg in watchdog "Attempting to re-run cron while it is already running." And now I have about 10 of those, each time I load a page (of course, that is what PMC does!). So, will be disabling that...
+1 poormanscron
This is almost a de rigor install for me now; many hosts have uneven cron support and I hate the month later "cron hasn't run" surprise. They higher the SLA, the less the need for poormanscron, but it works great. Just watch the logging, though. It is chatty if you use default settings.
mysql test? guides for eval & testing modules?
domineaux wrote: "... I also frequently run a test of Mysql after I remove a module that was previously installed."
what kind of mysql testing do you do for these regression checks?
On the topic of evaluating and installing modules, is there any good general guide out there to what to do to:
- evaluate a module for possible use
- what warning signs to watch for when considering a module
- how to do pre-testing
- installation
- regression testing of the module and any site effects
- removal & recover if necessary
any good docs or discussions of this whole area? (other than this thread ;-)
thanks,
jeff
This is an excellent
This is an excellent candidate for it's own thread!
This just came up in the
This just came up in the discussion we were having in IRC. Bump!
CRON or cron(.php)?
Please be specific about which cron we are talking about. There is the Linux CRON service which runs commands at specific times and which can generate error messages. Then there is the cron.php or Drupal cron that can generate error messages. Which is generating the "cron run failed"?
Thanks.
Its some component within the
Its some component within the cron.php that is causing the failure I believe. I was able to get into his server via terminal however there appeared to be some platform inconsistencies around php5 being executed from a ramdisk that I was unfamiliar with. There is also a notice regarding the failure of ZendOptimizer to load during execution.
I'm thinking that the host doesn't provide the full php at the CLI. Watchdog was also not reporting anything at all and getting into his mysql database didn't occur to me until much later but it seems like looking at the log tables in mysql would provide more specific insight.
That's sounds pretty hairy.
That's sounds pretty hairy. No guarantees I'll find anything but I'm willing to try.
Minor addition
As one of my colleagues just pointed out - I am aware that running cron should be done using wget however, watchdog wasn't reporting at all and I was grasping for any feedback whatsoever.
Tuesday update
Watchdog is giving me steady helpings of "Cron has been running for more than an hour and is most likely stuck."
Watchdog also was upset with some "Duplicate entries" involving url_alias but I seem to have resolved that with some path_auto and core path module patches.
If I log in to CP (Hostmonster) and view Process Manager I see: 6544 /ramdisk/bin/php5 /home/focfouuo/public_html/index.php
That stays forever, I have left it alone for hours and it still runs indefinitely.
I have tried "kill process" successfully and deleted cron items from variable table and still get "Cron run failed" when clicking on "run cron manually" on /status.
@tingham I removed the scheduled cron via Cron Jobs in the CP and am only running it via Drupal /status now to ensure some level of control and consistency.
CRON RUN SUCCESS
I've temporarily fixed it before, so I won't get too excited...
I can't be 100% certain what fixed it, but I went into URL Aliases and deleted all content. I also changed a few settings like how content is assigned the alias and what to do with conflicting nodes with same alias name.
The reason for this: importing iCal feed (Google Calendar).
say you have event 'TriDUG Hack Night' and have it set to repeat every month on the 2nd Wednesday. Well, URL Alias (aka Pathauto module) get confused b/c it has 20-50 (depending on how far in the future it looks) nodes with the same title and thus the same url alias. I could be explaining this incorrectly, but this is my belief.
Let's see if I can break the site again.
Oh, just remembered, I disable the iCal parser, so that could be it too. I'll run cron a few times and then if all goes well re-enable iCal parser and see if it breaks cron again.
FAIL
I left the house for an hour to go vote. Get back, click on 'run cron manually' and get a nice red 'Cron run failed'. I go to watchdog and all I get is a "Cron has been running for more than an hour and is most likely stuck."
Here we go again...
Ah! more info
Shoulda checked my email first. Received this from HostMonster tech support:
I ran cron.php for you from the command line (php5 cron.php) and watched the results. It appears that it is using quite a bit of CPU while running, and takes quite a while to complete, much longer than the usual 5 minute time limit for processes on accounts without a dedicated IP address. It may be that after it runs successfully, additional runs will be much quicker. If not, you may need to analyze the tasks registered with Drupal's cron system and see how to reduce them.
Any processes that run longer than five minutes are automatically terminated by the server unless they are attached to an active ssh session, and processes that use too much CPU result in all processes on your account running more slowly until the CPU usage drops. I have set the php5 cron.php process to run in the background for now in hope that it will complete, but you should watch the Process Manager in your account control panel to ensure that it does not run too long and kill the process if it does. I started it at about 10:50am Mountain Time.
I had a similar problem
I had a similar problem running cron on ibiblio.org. Clips from my email files:
I started getting log messaged like:
cron 01/30/2008 - 08:00 Cron has been running for more than an hour and is most ... Anonymous
warning cron 01/30/2008 - 07:00 Attempting to re-run cron while it is already running. Anonymous
error cron 01/30/2008 - 05:00 Cron has been running for more than an hour and is most ... Anonymous
error cron 01/30/2008 - 03:00 Cron has been running for more than an hour and is most ... Anonymous
warning cron 01/30/2008 - 02:00 Attempting to re-run cron while it is already running. Anonymous
I also got "MySQL server has gone away" messages.
June 2008: Hi Judy, Now that mysql.ibiblio.org has been upgraded to 5.0.51, are you still seeing the cron errors?
Yes, but not many. I get about one a day.
Hi Judy, We upgraded MySQL to the current stable 5.0.67 a month or so ago. Are you still seeing the errors? They're likely just hitting MySQL's maximum run time for a given process.
They are rare now. Maybe once a month. I had one this morning
It makes sense that you would see one this morning. One contributor's code gets hung up and bogs down the server, and did so this morning.
Judy Hallman
Wednesday update
So, I worked all day yesterday on this problem. I did not touch it for about 12 hours overnight. I just tried running cron and get this msg on watchdog: "Cron has been running for more than an hour and is most likely stuck."
Seriously? I would think 12+ hours is more than enough time for cron to finish it's job.
<>
Drupal is really lacking in diagnosis assistance here. I cannot believe I've wasted close to 100 hours of my life trying to fix this problem!
Back to the grindstone. I really truly doubt I will fix this today, or ever. I've done everything I can think of and sent hours searching the internet for answers.
have you tried installing
have you tried installing poormanscron or one of the other drupal cron modules?
Cron is a server function, not part of Drupal. I'm pretty sure it is your server that is not giving you helpful feedback, not Drupal.
I understand, but isn't it
I understand, but isn't it correct to think that Drupal is causing the fail? I mean, I would think if I uninstalled Drupal completely the cron job would run smoothly.
I'm starting to get a lot of errors mentioning menu_router...
I disabled Pathauto b/c that was causing many errors as well.
What's causing the failure?
If the cron failure were due to Drupal, then this issue would be replicable in other environments by others, but it isn't. You can hit a nail with a hammer at a 45° angle and bend the nail, that's not to say that it's the hammer's fault. I haven't seen cron issues as described here, and I've written what I've done when cron doesn't run as expected. That's not to say there's not a problem with your Drupal implementation. There are a large number of failure points. If this were me, I'd try to replicate my Drupal configuration outside of the host environment; such as on my own machine and then watch processes and do a post-run apache, mysql and php log check after issuing a cron run from within the Drupal interface and go from there.
Otherwise, there's been plenty of solid advice offered here.
I have run this test with 2
I have run this test with 2 separate hosting providers, one of which claims to be "drupal centric". Had exact same results on each image.
I don't know how to run Drupal locally.
Running Drupal Locally
I have successfully set up Drupal to run locally on both my MacBook and on my Dell Mini 9 with ubuntu.
On MacBook, I used MAMP (http://www.mamp.info/). You click install, then start the apache and MySQL servers and put the Drupal somewhere under the htdocs folder.
On ubuntu, use Synaptic Package Manager. In the Edit Menu, select Mark Packages by Task, then select LAMP server. This will automatically install everything you need. Put Drupal files under /var/www. Drupal has pretty good instructions on how to set up Drupal manually. http://drupal.org/getting-started/install
You can find your site at http://localhost/.
I think you will find the localhost is a good place to experiment with these issues. I have had no problem running cron in either OS X or ubuntu.
On Windows there's WAMP and
On Windows there's WAMP and XAMPP - both of which have ample documentation online to help you setup a local dev environment.
second vote for Xampp. Easy
second vote for Xampp. Easy install and works flawlessly.
There probably is some Drupal
There probably is some Drupal module that is contributing to the cron failure (or some weird mix of drupal Modules that is causing a bug), but you said "Drupal is really lacking in diagnosis assistance here," which is an unfair statement, because the error is occurring outside of Drupal, and thus Drupal can't give you diagnosis assistance.
It just bugs me to see blame being laid on Drupal for an issue (in this case - lack of diagnosis help) that is independent of the CMS -- this is the sort of thing that breeds misconceptions about how "hard" Drupal is to use. I think a lot of people end up pegging Drupal as "too hard" because they try to do things with Drupal for which they lack some required set of skills - e.g. trying to diagnosis a server issue when you have little server admin experience, trying to create a custom theme when you have little html/css experience, etc.
I have on paper (will show
I have on paper (will show you tonight) where I have systematically disabled modules... I get cron to work and start enabling modules... cron fails... I go back and forth and there is nothing that shows a point where a module is causing cron to fail. this isn't blame, just explaining why I'm having such a hard time.
It seems that a module is causing this, but there also seems to be no way to diagnose that I know of.
Just got off chat support with Hostmonster, what a complete TOOL!!!!!
Brandon [9:57:25 AM]: I have been struggling with this problem for over a week now. I think I need my time avail to execute cron (write to db) increased. I'm using Drupal btw.
ndickson [9:58:53 AM]: the default time for all processes on the shared ip is 5 minutes.
[9:59:06 AM]: If you need to run processes longer than that you will need to purchase a dedicated ip.
Brandon [10:00:07 AM]: wow, 5 minutes should be plenty of time
Brandon [10:00:28 AM]: do you see anything unusual, any error msgs or anything eating memory?
ndickson [10:07:05 AM]: No, I do not see anything unusual you asked me about increasing execution time for your cron. I answered that question.
Perhaps there should be some
Perhaps there should be some disclaimer or warning that if you don't have a B.S. in Computer Science you shouldn't even bother with Drupal?
Hopefully Drupal 7 will work better with some modules being brought into core and thus better supported I would assume. Lessening the need to go in search of modules that may or may not work / follow good coding practices.
My hosting provider says it's nothing on their end (I've done live chat, submitted tickets, emailed with them), "Drupal" says it's not on it's end.
So what the hell am I supposed to do?
I'm going to see if I can teach myself how to install Drupal locally and see what happens. Unfortunately I 'work' at home so don't have anyone to assist me with all my bothersome questions.
If you really feel that way
If you really feel that way about Drupal, I think you probably would benefit from a hosted CMS solution, where you don't have to worry about any of the nasty server-side issues and have a dedicated organization to go to for support. Drupal Gardens will be just that when it launches, but until then, here are a few other options for you.
LightCMS - http://www.speaklight.com/
Ekklesia 360 - http://www.ekklesia360.com/
Cushy CMS - http://www.cushycms.com/
"My hosting provider says
"My hosting provider says it's nothing on their end (I've done live chat, submitted tickets, emailed with them),"
that was in reference to HostMonster.com just to let everyone know. not HotDrupal.com
Perhaps another solution
How about using something like SuperCron (http://drupal.org/project/supercron). I haven't tried it but if it can "See the list of all Cron hooks found in the enabled modules" you might be able to identify if there is a specific module that is hanging Drupal's cron.
Dave
Installed SuperCron.
Installed SuperCron. Everything works fine, everything runs in "0" seconds except search (2 seconds).
To clarify, when I say
To clarify, when I say "Everything works fine" I mean Cron still fails, SC does not show anything for me to consider a suspect though.
I think you hit on something.
I think you hit on something. Try the WAMP local server and run the cron or poor mans cron.
Serious, I think your problem is with your hosting provider.
I've gone through a world of hurts with so-called expert host server support people. I have had them chew my tail, when the problem was on their end. That has happened many times, try installing the CivicCRM or the Magento or some of those applications that use variations of MySql. Yipes, it took me three days to solve issues with the host support people installing Magento.
Also, remember... you can get a reseller account and sell hosting. It takes absolutely no experience or qualifications to be a hosting server.
I don't know what your interests are with Drupal, but if you are serious about site building. You will be making a mistake, if you really haven't had a decent working experience with Drupal.
It took me awhile to learn Drupal competently. I built a site yesterday in a couple hours and with just a few more tweaks it's a done deal. I couldn't do that and have a competent database site with anything else I'm aware.
Everytime I look up there is a new module and the developers aren't trying to screw me over to buy the module either. The devs for Drupal are serious about Open-Source and that makes this an extremely vibarant and enthusiastic group of people. I remember having to buy all kinds of modules for Joomla, and the developer would fade into the sunset within a couple months. There was no support available when the dev quit answering their email or quit posting on their proprietary forums. This has a happended a few times on Drupal, but not often.
Run cron manually, bypassing any imposed constraints
If you remember, I suggested that we try running the cron task manually and removing any time/memory limits on the server while it runs.
I think I suggested this on October 30th @ 11:50am:
Rather than you continuing on w/ trying to delete modules, etc. this was my recommendation as the first thing to try.
The other thing we could do is clear out all the statistics for your database. As we can track things on a per-table basis (updates, selects, inserts, etc) it would possibly give you an idea of what tables may be causing issues. We would know if your cron run is causing, for example, thousands of UPDATES or INSERTS into a table. Another possible clue would be to look at the SQL process list to see if there are any queries which are taking an abnormal amount of time to run. Another thing to check would be how much CPU is getting burned up - is PHP sitting in a state using zero CPU, or a state where it is at 100% utilization.
Steve
I wrote you back that
I wrote you back that day:
So, I didn't think it was FeedAPI b/c after totally uninstalling it cron was still failing.
Sent e-mail
Well, I don't want to carry on this conversation too long here in groups as others will get bored.
Guess I interpreted that as an indication you were trying things, and would let me know when you were ready to try my suggestion.
I think the thing to do is setup a time when we can talk on the phone, and at the same time trying to see what info we can from running cron while nothing else is going on. I moved the support ticket you opened into my personal ticket Q after sending you a response.
Add a reply to the ticket and let me know when you will be around tomorrow or the next day and let's work out a time when we can do a manual run and watch things like CPU, SQL usage, etc. and find any clues to what's going on or what may point to a specific module. I think doing it, and talking on the phone back and forth, would be the most effective.
Then we can stop boring all the other people here :)
Steve
ATTENTION
Shut this thread down. No more posts please. Waste of time.
It's dark in there
Any module can hook cron and it is likely only one of your modules is stuck.
That module might be stuck on a MYSQL access. Checking your database is easy if you are using the default MyISAM engine.
On Ubuntu, the databases are in /var/lib/mysql/{database name}
In that directory myisamchk *.MYI will look for crashed tables.
My watchdog table has been corrupted more than once. Clearing cache will decrease the length of time. You can also empty (not drop) the watchdog table. You might look through the contents first.
If you are not a "coder" turning on logging probably won't shed much light. I would disable modules one at a time and see if life improves.
Jim
The fix
myisamchk -r *.MYI