system_update_files_database() called from update_get_projects() breaks system table on cache clear

Retitling.

Please confirm whether you can do a clean install with latest HEAD (and whether running update.php or cron.php causes the same error).

Also just a general note that HEAD-HEAD (or alpha to alpha) upgrades aren't supported yet.

I can reproduce this with a relatively clean HEAD install.

Go to update.php

Run run updates (even if there aren't any), click the go back to your site button.


Error message
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 414 of /home/catch/www/7/includes/menu.inc).


I have a bad feeling this might be the system_list() cache - try removing the caching code from system_list() and see if that helps. This has been working for ages, so something recent must have broken it (I vaguely remember a patch adding cache_boostrap() to drupal_flush_all_caches() / system_flush_caches() so could be that?)?

This has to be related to the failing update.module tests, see http://qa.drupal.org/pifr/test/32. I can see the same there, only the profile and the themes are enabled. I tried to debug this for hours now, no luck so far.

See #566494-144: Running cron in a shutdown function breaks the site (and 145).

@ #7 If I had to guess, I would say you had update.module installed before and now you don't?

Adding the alpha blocker tag since this is proper site hosing stuff.

Marking this as a duplicate of the cron bug.

I've been getting the same error for at least a week now:

Fatal error: Call to undefined function user_access() in J:\XAMPP\htdocs\drupal7-HEAD_unpatched\includes\menu.inc on line 580

This is on an unpatched clean HEAD installation. The strange thing is the installation did work all right yesterday but today I get the error message without any changes to the code.

I tried emptying the usual suspect tables in the database to no avail.

Subscribing.

I can repro this with a Feb 8 build by deleting the system_list entry from the cache_bootstrap table. I don't follow why this is a dup of the cron bug, but I'll trust ya'll as I'm not qualified to debug this :)

Problem persists. Did a clean install yesterday after #566494: Running cron in a shutdown function breaks the site (#150) had been committed to CVS. Setting this to "active" again.

EDIT
The above mentioned patch seemed to have been rolled back. I don't think these issues are (directly) related.

EDIT 2
When calling the /authorize.php script I get the following error message:

Warning: register_shutdown_function(): Invalid shutdown callback 'system_run_automated_cron' passed in _drupal_bootstrap_full() 
(line 4523 of J:\XAMPP\htdocs\drupal7-HEAD_unpatched\includes\common.inc).

EDIT 3
Problem persists. Some time triggered process (automatic cron run?) sets the whole status column in the system table to 0.

Try these steps to reproduce the error:

1. Install the most current HEAD version.
2. Wait till the automatic cron run should have been triggered for the first time (default is 3 hours but you can set it to 1 hour on the site-information page).
3. Clear the caches manually.

This is on XAMPP 1.7.1, Windows 2000 SP 4.

EDIT
Restoring the system table and emptying the cache_bootstrap table (especially the system_list entry) restores the system.

Any subsequent manual clearing of the cache after a cron run destroys the status column of the system table again.

EDIT 2
The status column is actually empty _before_ clearing the cache, so the culprit must be the cron run. The system works ok even with those status fields set to 0. Clearing the cache triggers the above mentioned error message and renders the system unusable.

Got a new error message for a change:

Fatal error: Class 'DrupalQueue' not found in J:\XAMPP\htdocs\drupal7-HEAD_unpatched\modules\update\update.fetch.inc on line 103

See above and #708832: Fatal error: Class 'DrupalQueue' not found and #686196: Meta issue: Install failures on various hosting environments.

This is almost certainly due to http://api.drupal.org/api/function/system_update_files_database/7 which is triggered by update_get_projects(). There's some static caching in update_get_projects() - it puts projects into an array, then sets $project['status'] to FALSE in certain circumstances, but that shouldn't in any way get saved back to the db, and if it did would have to be a bizarre race condition. So it's more likely that system_update_files_database() is broken. However I don't seem to be able to reproduce the bug now, so can't track it down further.

@catch

Thanks for looking into this and pointing me to a probable suspect ;-) Will have a look.

@catch

See my second EDIT from #16:

The status column is actually empty _before_ clearing the cache, so the culprit must be the cron run. The system works ok even with those status fields set to 0. Clearing the cache triggers the above mentioned error message and renders the system unusable.

So I'm still not sure about the root cause for this isssue.

update_cron() also calls update_get_projects() - so it may well be setting the status to 0 within the cron job rather than a regular cache clear.

The system working fine afterwards will be down to system_list() caching and that not being cleared on the initial cron run which breaks the system table. Once it gets rebuilt the bug shows up.

I've been looking at the API documentation on queue operations and the six occurrences in the source code of update_fetch_tasks as this is the only entry in the queue table. $queue = DrupalQueue::get('update_fetch_tasks');

The related function is function _update_create_fetch_task($project) (update.fetch.inc, line 232).

The system also makes no guarantees about a task only being executed once: callers that have non-idempotent tasks either need to live with the possibility of the task being invoked multiple times in cases where a claim lease expires, or need to implement their own transactions to make their tasks idempotent.

Could the queue system be causing some race condition?

I can't find any reference to $queue->createQueue(); in that file. The queue seems only be registered and items added (line 239f):

 $queue = DrupalQueue::get('update_fetch_tasks');
 $queue->createItem($project);

I'm moving this to update.module - since it's clear the error is triggered from there, although that may not be the only possible way it could happen. Also marked #709386: Schema Version reset to -1 when update.module cache is cleared as duplicate.

Getting this error message when manually running the update script:

Fatal error: Class 'DrupalQueue' not found in J:\XAMPP\htdocs\drupal7-HEAD_unpatched\modules\update\update.fetch.inc on line 239

Therefore linking this issue to #708832: Fatal error: Class 'DrupalQueue' not found (EDIT, was wrong link).

I believe this problem (at least as described in #16) is caused by #566494: Running cron in a shutdown function breaks the site and in particular the fact that cron is being called from a shutdown function.

See the notes at http://php.net/manual/en/function.register-shutdown-function.php about the effect of shutdown functions on the working directory of a script, in particular:

Note: Working directory of the script can change inside the shutdown function under some web servers, e.g. Apache.

If I'm right, the attached patch is a workaround for the problem. But the real fix is probably at #566494: Running cron in a shutdown function breaks the site. I think we should probably mark this a duplicate of that one again, but I haven't read this issue closely enough to know if it encompasses other problems also.

This looks like a duplicate. Let's concentrate efforts there, then re-open this if for some reason there's another issue.

#566494: Running cron in a shutdown function breaks the site

Thanks, will try the patch(es) and follow those other queue(s)!