Separate to Unique Cron Job
eyecon - June 10, 2008 - 20:33
| Project: | Update Status |
| Version: | 5.x-2.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
This is an important module and is a drush dependency. Unfortunately, it causes cron to get stuck from time to time which requires clearing the cron variables (last_cron and semiphore) from the variable table and then flushing the cache.
This is a VERY frequently reported issue.
It would be helpful to be able to schedule something like update_status.php independent of cron.php.
#1
The same problem in Drupal 6.
#2
I suspect this is relating to an issue I've observed in that the Update Status log is NOT showing new releases even though they exist and I've done a manual CRON job to check such things. Today, for example, I got notice from the Security Team indicating the Printer, e-mail and PDF module:
http://drupal.org/project/print
Has the same highly critical vulnerability in regard to unrestricted e-mailing (spam) as the Forwards module as reported here:
http://drupal.org/node/398564
However, upon logging into one of the sites using this module, checking the Update Status log after doing a CRON job, it did not detect the new version.
Would also like to suggest something be added into the documentation for this module. As you would think, when you click on that 'check manually' link, it is going to go out and fetch the latest info. (Which apparently is not always true!!!)
If this issue is not the same as the one appearing at the head of this thread, then I apologies. Let me know and I will start a new thread...
#3
@Irene Kraus: Probably the issue you hit was #184418: update(_status) results stale for up to 6 hours.
#4
I doubt this is going to happen in D6. Maybe it'll happen in D7, but I doubt it.
However, there are massive problems with how update status (in D5 and D6) cache their data in certain configurations, and it turns out that the data is always cleared when cron runs. :( Those are now fixed in core, and I'm backporting to D5:
#155450: backport separate {cache_update_status} table and private non-volatile cache API from D6 core
#220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc
So, even without a separate cron job, life should stop sucking for cron + update(_status). Hence, "won't fix"...
#5