I have a working Drupal installation that uses the 4.4.1 and the xtemplate / pushbutton.
This installation hosts 3 separate domains on one installation, in the same database, but with different prefixes in the conf files.
I tried to upgrade to yesterday (2004-09-26 CVS), and ran into problems.
Here are the steps I did:
- Created the users_roles and locales_meta tables for each domain
CREATE TABLE site1_users_roles ( uid int(10) unsigned NOT NULL default '0', rid int(10) unsigned NOT NULL default '0', PRIMARY KEY (uid, rid) ); CREATE TABLE site2_locales_meta ( locale varchar(12) NOT NULL default '', name varchar(64) NOT NULL default '', enabled int(2) NOT NULL default '0', isdefault int(2) NOT NULL default '0', plurals int(1) NOT NULL default '0', formula varchar(128) NOT NULL default '', PRIMARY KEY (locale) );
(same for site2, and site3)
- Ran the update.php script
At this point, I can browse the site with no problem.
However, when I go into the admin menus and change anything (I tried going into admin/themes and unchecking 'primary links' one time, and tried to remove the path to the logo at another time), and then clock on Save configuration, the site becomes unusable with the following message for any access:
Fatal error: Maximum execution time of 30 seconds exceeded in /home/myusername/html/includes/menu.inc on line 653
The two other sites are unaffected, until I try to change anything in the admin menus, then it is ruined as well.
I tried going into the database and deleting the variable 'theme_settings', but the results were the same (time out of script).
Luckily, this is just my test site at home, and not the live site, otherwise it would be a big problem.
What is going on?
Comments
Even no need to update anything
Well, I did one more test. I decided to just browse the admin menus, and not update anything there. After sometime, it experienced the same symptom (script timeout), without me updating anything! Very strange.
Here is a database dump of the last few accesses in the access_log table before the system locked up, sorted descending by timestamp.The last successful access was to admin/settings/story. Nothing worked after that:
The code that causes this in the following function, specifically on the array_unshift() line:
If I comment out the while loop and what is inside it, the page does display, but the dynamic menus are invisible.
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
More investigation
Well, I tried doing the following:
I added the line:
Before the commented out while loop (see previous comment), and here is the output:
I am not sure what to make out of this, but the 'node/5/view' seems like it should be 'node/view/5' doesn't it?
And what about pid being negative? Would that affect the loop?
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Similar problems
I've had similar problems trying to upgrade from a 4.4.0 release candidate to 4.5 (cvs) so I tried installing a fresh 4.5 install and had the same problem ("Maximum execution time exceeded"). Like kbahey I am using table prefixes, but I am running postgresql.
I did find some errors in the update.php file where the braces {} were left off the table names.
Eventually, I tried an installation from scratch but I got:
Similar symptom, different code
Seems that the symptom is similar, but the code is different in each of the cases.
Yours in in theme.in mine is in menu.inc
Seems that your problem is not related to an upgrade as well (if you started with an empty database). I urge you to submit a bug report on it then. Mine is most probably related to the upgrade.
Either that, or the CVS version is still unstable.
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Database update failures
I tried the upgrade again. So I loaded the old database backup, then ran the update.php script again.
The update script select 2004-05-10 as the date that updates after which will be applied.
I noticed that there were some failures
Some of those are not an issue (e.g. the users_roles and locales_meta, which were created manually before the update). The rest are problems, but I am not sure if they are related to the problem at hand or not.
Here is a copy and paste of the failed portions:
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
It is probably the cache
I am not 100% sure yet, but after an evening of testing, I think this has to do with Drupal's cache.
I recall when I first installed Drupal about a year ago, I had some problem with the cache (can't remember what), and turned it off ever since.
Cache is still off, but it seems the newer versions of Drupal cache other things, caches the filter, the menus, ..etc. regardless of what the cache setting is.
When I delete the site1_cache table, the site starts to work for a bit, then gets stuck again.
Did anyone face something similar to this?
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
More troubleshooting
I tried to do some more troubleshooting.
I reloaded the old database, ran the update.php, then saved the database dump (before.sql). Then I went to /admin/settings and pressed 'Save' (without changing anything), and I got the script time out error message. I then saved the database dump to another file.
I ran a diff between the two databases, and here is the result. Drupal inserted several rows in the menu table for various menus. Also, it inserted a sequence for the menu id. It also cached something in the session.
Can anyone familiar with the menus and cache code see anything that could be the reason for the menus timing out? I am stuck on this.
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Solved!
Well, finally I have a solution to this.
That is it. The site works perfectly now. I am not sure what menus will be lost when this is done, but they can be rebuilt manually, rather than having your site not functional.
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba