Running cron does not check for available updates

Just checked this with HEAD that was checked out today, and I can confirm that this is still an issue on a fresh installation.

After looking at the code some more, it appears that running cron does not actually check for available updates, and thus will not make the message go away.

function update_cron() {
  $frequency = variable_get('update_check_frequency', 1);
  $interval = 60 * 60 * 24 * $frequency;
  if ((REQUEST_TIME - variable_get('update_last_check', 0)) > $interval) {
    // If the configured update interval has elapsed, we want to invalidate
    // the cached data for all projects, attempt to re-fetch, and trigger any
    // configured notifications about the new status.
    update_refresh();
    _update_cron_notify();
  }
  else {
    // Otherwise, see if any individual projects are now stale or still
    // missing data, and if so, try to fetch the data.
    update_get_available(TRUE);
  }
}

I think that the problem is that 'update_last_check' is 0 when the system is first installed, so the first code path will always be taken, but those two functions do not set 'update_last_check', so it is always 0 and the first path is always taken. Am I on the right track here?

If I do the following:

delete from variable where name = 'update_last_check';

truncate cache_update;
truncate cache;

and then go to admin/reports/updates, the update status will be updated automatically.

Please check that your Drupal install can actually access update.drupal.org.

still works if I throw in a truncate cache_bootstrap;

Is that from a brand-new fresh install of Drupal 7? My install can access update.drupal.org, because when I click the "check manually" link it is run successfully.

Also, the issue is not with checking for updates not working when you go to admin/reports/updates. The problem is that on a new installation of Drupal 7 it is not running when you click "run cron" when the message implies that clicking "run cron" will solve the problem.

Hm. I guess this logic is slightly broken.

1. We want to run update_fetch_data() unconditionally at each cron run to process the queue
2a. If the update check interval is elapsed, there are no tasks pending process and we haven't previously called update_refresh(): we want to call update_refresh to register new tasks, followed by a new update_fetch_data()
2b. If the update check interval is elapsed, there are no tasks pending process and we have previously called update_refresh(), call _update_cron_notify() to notify the administrator and update the last_check

Here is a started patch.

Here is my attempt. It is fairly naive. I just added a call to update_fetch_data() inside update_cron(). It will be called every time cron is run now. It solves the original problem, but is probably an inefficient way to do it.
I also added a test to check that running cron makes the notification about updates go away.

Sorry for the double post.

jergason I thik you entered a newline to much.

So I did. Rerolled the patch to fix whitespace.

This problem still happens in 7.0 beta1.
jergason patch works but is a little bit inefficient.

update_cron basically does this:

if (update interval is elapsed)
  update_refresh
else
  update_get_available

I think it's fine if we remove the "else", and we run update_get_available unconditionally every single time. This function checks if re-fetch is necessary and will call update_fetch_data in that case.

Patch attached. (Jergason test not included)

Fixing component so the right people see this.

thanks

Don't understand. Test failed when checking this: $this->assertText(t('No update information available.'));
But manually I see that text.
Can someone shed some light here?

Indeed, sorry I didn't see this earlier. I only watch the update.module component... Thanks for moving this webchick!

I'll admit these code paths are a bit hard to follow, and I haven't looked at them closely in months, so off the top of my head, I'm not sure what to propose here. I will point out that whatever we do, we should make sure that we don't make the bug I reported at #934300: Update status keeps trying to fetch available updates over and over for projects without a release any worse. ;)

Anyway, I hope to come back to this soon, but I've been spending *way* too much time on the Update manager issue queue over the last week or so, and I really need to get back to focusing on my day job and other things in the near future...

I am having this same issue. I just recently upgraded my Drupal install from 6.19 to 7 beta 1, and I can not retrieve update information. Any idea on how/when this can/will be fixed?

Metropolis26: A temporal solution can be clicking "Check manually". That should work, isn't it?

Corbacho: When trying to run update manually I get the following error,

Failed to get available update data for 7 projects.

Problem is still there in version 7 beta 2. Brand new fresh install and the following error appears.

Error
HTTP request status Fails
Your system or network configuration does not allow Drupal to access web pages, resulting in reduced functionality. This could be due to your webserver configuration or PHP settings, and should be resolved in order to download information about available updates, fetch aggregator feeds, sign in via OpenID, or use other network-dependent services. If you are certain that Drupal can access web pages but you are still seeing this message, you may add $conf['drupal_http_request_fails'] = FALSE; to the bottom of your settings.php file.

Cron reports that it has run when started manually, but error is still appearing.

Sorry, but I'm marking this one major. It might even be critical, as such an out-of-the-box error might be a show-stopper to new D7 users.
Currently, it seems the update information isn't retrieved at any cron run. And while it is possible to check it manually, the next cron run after the configured update interval has elapsed, will show again "No update information available."

We will have to take care at dww's objection (#20), however I'm not sure it has something to do with this issue.

Here's a reroll of corbacho's patch #15, now including jergason's test in #14.

Just marked #962802: Status update never runs through cron unless first manually triggered as a duplicate of this.

+++ modules/update/update.module	5 Jan 2011 04:10:02 -0000
@@ -296,11 +296,9 @@
     update_refresh();
     _update_cron_notify();
   }
-  else {
-    // Otherwise, see if any individual projects are now stale or still
-    // missing data, and if so, try to fetch the data.
-    update_get_available(TRUE);
-  }
+  // Now see if any individual projects are now stale or still missing data,
+  // and if so, try to fetch the data.
+  update_get_available(TRUE);

Try inserting update_fetch_data() between update_refresh() and _update_cron_notify() instead.

+++ modules/update/update.test	5 Jan 2011 04:10:02 -0000
@@ -68,6 +68,16 @@
+    $this->drupalGet('admin/modules');
+    $this->clickLink('Run cron');
+    $this->assertNoText(t('No update information available.'));

Replace with
$this->cronRun();
$this->drupalGet(...);
$this->assertNoText(...);

Let's trace through what happens in update_cron():

If 'update_last_check' was a long time ago (or we've never run cron before), we run

• update_refresh() which populates a queue of modules to check.
• _update_cron_notify() which send an email if your modules are out-of-date.

Never in here do we process the queue, nor do we ever set 'update_last_check'. So we never can get to the second code flow branch, which runs update_get_available() and attempts to process the queue.

Attached is a patch which calls update_fetch_data() after update_refresh(). Fixes the behavior for me, but causes a bunch of tests to fail -- perhaps because we're now doing too good of a job checking for updates so the workflow has changed a bit.

I'd appreciate some manual testing on this patch, and if somebody wants to tackle the failing tests, that'd be wonderful as well! (There's more information about this bug in #962802-11: Status update never runs through cron unless first manually triggered.)

please post a working patch for this issue on brand new D7 Stable...

I don't understand why the tests are all failing... but then I don't understand the messages the tests are outputting and what they are trying to do.

@joachim: Run the relevant tests locally. Then you can look at the actual page Drupal returns and compare it to the assert statements about the page content.

It's been a while since I looked at this and it'd be great to have another set of eyes on the problem.

I took a look at this for a little bit at the code sprint yesterday. I didn't make much progress, but I just wanted to point out that the 3 exceptions in testing are because of a separate issue with Simpletest.

http://drupal.org/node/1089792

#29: 647964-29-do_not_forget_to_fetch_data.patch queued for re-testing.

Thanks @webchick for dredging this one up.

I've worked out the test failures in #29. The patch in #29 makes cron actually attempt to fetch a list of available updates. Therefore when we visit admin/modules, we aren't told that we need to manually check for updates since cron has already run. (But it is important for us to update the stale data to actually test the update module!)

I've worked around this by manually checking for updates in admin/reports/updates. Another option would be to flush the update status caches, but I haven't looked into that.

I added a test for this issue, inspired by Pancho in #25 to test for this.

Attached are two patches. The first is only the tests, including the new test and the changes required to the tests in #37. There should be only one failure arising from the new test.

The second patch includes the fix in #29 as well as the tests.

Perfect - just as predicted!
Seems like we got this one... :)

Is this patch committed?

Great work! :)

Committed to 7.x and 8.x. Thanks!

I spent a bit of time looking into dww's concern #20, but I don't really think these two things are related; this patch merely makes sure the function which occasionally causes "stuckness" actually gets called. And has expanded tests to prove it, too! Yay! :)

Is anyone still facing this problem with Drupal 8?

I am facing this issue on two live sites. If I check manually it loads the information info and shows it on the page, however, if run cron, it doesn't do anything and the page keeps blank.