Drupal pet peeve: cron.php

Filed under: Uncategorized. Tags: , ,

I hate that I have to manually (or scriptedly) call cron.php for every Drupal site I run. Even for multiple Drupal sites on the same server in a multisite configuration. Yes, there are ways to automate it, but eventually they fail. I just manually called cron.php on one of our main sites, after realizing it had silently failed for the last 32 weeks. Hundreds of reminder emails are being sent out now, for events that were held months ago. Yes, there are modules to have cron.php called periodically (poor man’s cron…) but they’re flakey at best, and risky at worst (there is a chance of overlapping cron.php calls if the timing is just right).

Anyway, there endeth the rant. D’Arcy’s Drupal Pet Peeve #1: cron.php

Comments

12 Responses to “Drupal pet peeve: cron.php”

  1. Tim on June 22nd, 2007 8:34 pm

    Ahh — that explains the Drupal Showcase and Discussion reminder for Nov. 21st that I just got.

  2. dnorman on June 22nd, 2007 8:56 pm

    yeah… sorry about that… I’m betting there were hundreds of emails sent out. dangit. I’ve got some apology emails to send on Monday…

  3. Jim on June 22nd, 2007 9:12 pm

    What does cron mean? I don’t remember ever having to deal with such a scripting call. Oh, wait, I use Wordpress for all my heavy lifting, never mind.

  4. dnorman on June 22nd, 2007 9:13 pm

    I’d take that as a shot at Drupal, but if you’re only using WordPress, you’re not really doing much heavy lifting… ;-)

  5. Jason on June 22nd, 2007 10:54 pm

    I had a similar problem to this a few months back. It turned out sendmail was in a hung state on RedHat, which I had the unfortunate pleasure to find out after a reboot for a kernel update. I tracked it down since then I noticed the exact same issue on the server next to it. I use wget in crontab to run cron.php and only ever had a problem on one site caused by a particular module; but there are definitely issues with cron.php I would love to see fixed, particularly cleaning up it’s mess if it happens to error out mid run.

  6. Lisa on June 23rd, 2007 4:37 pm

    Is it any consolation to know this also happens sometimes with Moodle?

  7. Sami on June 25th, 2007 11:22 am

    Here’s an example of a masscron.php file. You need a table that has the sites, created, and populated field… See the code for what I mean. You probably should add a timeout statement as as well. It even uses APC to save the results so it doesn’t have to fetch them from the db after the first time.

    http://www.etopian.com/masscron.phps

    Sami

  8. Sami on June 25th, 2007 11:27 am

    In addition to that script, I realize you have something similar, there should be a way to log it and report on indiscrepencies ? How did it fail anyway?

  9. dnorman on June 25th, 2007 12:19 pm

    Sami, thanks for the script. I’ll give it a shot. I’ve been using a shell script that crawls the sites directory and calls cron.php on all sites configured (relying on the $base_url variable being set in the file). It works pretty well, but I get no feedback if a site borks for some reason. Still have no idea why the site stopped cronning. The call to the multicron.php script was in the crontab, and other sites are being updated just fine… I’ll try to do some more in-depth forensics…

  10. Sami on June 25th, 2007 1:22 pm

    BTW, that’s works with Drupal 4.7, probably needs some changes for 5.0, let me know if it doesn’t and I’ll work out a 5.0 version.

  11. Raj on June 27th, 2007 10:23 am

    I’m finding the same thing - especially with the RSS reader, never pulling in new content.

  12. Justin - website design on June 15th, 2008 6:04 pm

    cron.php can be tricky, so has everything been resolved as of yet?

Leave a Reply




Readers who viewed this page, also viewed:

  • N/A
Creative Commons License
This work is licensed under a Creative Commons Attribution 2.5 Canada License.