Drupal pet peeve: cron.php

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

12 thoughts on “Drupal pet peeve: cron.php”

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

  2. 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. 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. 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. 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. 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.



  7. 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?

  8. 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…

  9. 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.

Comments are closed.