SIte corrupted with no administrative blocks any more after going to admin/build/modules

I'm in the same boat, and it doesn't have to do with the menu system specifically. 6.2 seems so janky that using it for production is suicide. This version should have never left the RC stage..

Ok, I'm having this issue too, and dont' have a pre-corruption backup. Is there anyone who knows what they're doing better than I that knows if (and which) database tables I could export/import into a fresh install of Drupal 4 or 5? I'm specifically thinking of content (forums and story) and my user list.

Dear Sir,
I am facing the same problem on local host also. What is the reason?
In addition what should I do to fix the problem, if I don't have db backup?
Rgds
Mahesh

Have the same problem. "You do not have any administrative items" at admin and some node pages don't show (redirecting to front page). And "Create Content" page is empty.

Is it possible to restore some defaults in database tables and save node contents? And how to avoid this database corruption next time with v. 6.2?

I have this same problem. Nothing on the admin page. What.

same problem here. without a db backup what can i do?

Also had this problem, not sure what caused it, but managed to fix it by going to admin/build/menu, and then going through each menu and hitting 'reset' for all menu items I could find that actually had this option.

I lost any customizations I had for those items, but after getting the menus back the way I wanted them, I had no more issues. Weird.

+1 for this issue in hosted environments.

Site5 hosting has a fixed 30 sec limit, a fairly common limit in these setups. This can not be changed.

One of the issues is that the rebuild menu function is called by multiple modules, including devel, rather than being included as part of the core process. As a result, my menu is rebuilt 6 times during a clear cache call.

If you can't find a workaround to solve this kind of problems (neither devel's rebuild menu, patches, etc) you will always be able to get the site working back if you enable the "admin/settings/performance" entry in the menu_router table access that page and clear the cache (if it results possible without timeout), this is a brute solution and certainly not the best one neither the fastest one.
Follow the issues below and find out how to create a php page to rebuild the menu, how to patch D6 for ALTER instead of rebuild the menu_router table, and many other alternatives.

- here I started a kind of index, it links to the real discussions: #289618: menu_router table truncated and site goes down: Transaction or Lock required for D6
- the development discussion, some patches to improve the chances but not real fix, developers talking about to solve the issue in D7 first and maybe backport it later to D6 (IMO it won't be fix unless a LOT of user complains about it, and the better the hardware the less chances to hit this issue): #238760: menu_router table truncated and site goes down
- a different symptom to the same issue: #246653: Duplicate entry in menu_router: Different symptoms, same issue
- the hart of the problem: #249185: Concurrency problem with variable caching leading to cache inconsistency
- more discussion marked as duplicated: #248739: Duplicate entry errors - lots of them
- being afraid to use D6 in production: #254616: SIte corrupted with no administrative blocks any more after going to admin/build/modules

sorry, I forgot to change the status: read above

A quick fix was to place a simple check on the menu rebuild function itself.

<?php
function menu_rebuild() {
  static $menu_built = FALSE;
  if ($menu_built) return;
  $menu_built = TRUE;
?>

This prevented 4 of the 5 calls, doubling the speed. This was being called by content_type_update($info) for each content type when invoked using module_invoke_all('node_type').

Not sure on side effects but sure beats the white screen of death. :)

if i go and do an update again (www.site.org/update.php) everything goes back to normal. i didnt have to restore the database. can s'one pls expalin this.

I installed Drupal 6.3 in a test server and i got the same problems. All the time was when I was installing modules. Right now I am getting "You do not have any administrative items" i can not instert any new content or administrate anything.

did u try an update to drupal again ?

You may also rebuild menu_router by DTools (wsod)
See also: #514898: "You do not have any administrative items." - Callback: system_main_admin_page() doesn't exist!

we were having the same problems and were slack on our backups. i thought all was lost but did the update and regained my sanity.

do the update people, it just might help you. props to harishu :-)

Hi everybody, I have the same problem on local, no memory problem, just before I changed all memory limits to 64M, it happened when I was trying panels on my drupal 6.12 and I tried update.php but it doesn't work ,and also no backups, please help!!

1) Try increasing your memory even more, and run phpinfo() to make sure that the system is actually allowing you to increase your memory limit. Some have restrictions on the max or simply ignore requests to increase it.

eg: just after the ini_set() type in the following:

phpinfo();
exit();

Look for something like max memory limit.

2) Are you sure that it is not some error in panels version? If it was a dev version, this would be the first thing i would disable and see what happens. (see 3)

3) If you have lightbox2 + cck installed, and high # imagecache / content types, turn lightbox2 off in the systems table using phpmyadmin or something similar (change status from 1 to 0) and flush the cache tables manually. These all start with cache_* or just cache.

This combo is about the most resource hungry of any modules that I have seen. #409354: Performance issues with large number imagecache presets and content types

4) Otherwise, disable some of the modules in the system table (take care with dependencies) and clean the cache and run updates. Then try running update.php again.

Good luck

apologizes to Alan D. @#26, but
what are you talking about?

it is not a memory problem, it is a Drupal problem #251792: Implement a locking framework for long operations

@torcuato: read above #17
it is a detailed explanation and links to alternatives to solve your "right now problem"
many of those solutions are equivalent and will bring your site back to live (then do a backup immediately)
the problem might come back and hit you again when using several tabs at the same time and/or views/panels or any intensive module

this should be gone when Drupal 6.16 comes out (according to the looking framework)

@arhak I guess that this is really a "no transaction rollback to handle fatal errors when updating core tables". You eleminate the error cause (memory), you do not have the error. Sorry, I was treating this as a request for help rather than an issue update.

I was assuming worst case, which has happened a lot to people. e.g. The entire site has been nuked. No admin functions, et al. Just a white screen or massively reduced functionality, which steps 3 - 4 come in.

Step 3 is an unusual case caused by this module combo. These settings are in the variables table and effect the performance no matter where or what you are doing. (Eg: these 1MB + variable cache entries were always loaded)

@#28 no, I wasn't criticizing your help support, rather questioning the proposed solution

you can increase memory to avoid it to happen, but IMO it is not a memory limit problem, rather a concurrency one
If you start opening several tabs in a browser and several of them attempt to rebuild the menu, you get stuck with a broken menu nevermind how much memory you had

moreover, if the site mentioned @#25 is down, what good might bring increasing memory?, that won't get it back to work

you suggested a "preventive" measure, but he asked for a way to bring the site back to live, right?
and most of the subscribers of this thread land here trying to figure out how to get it back
what causes it might not even matter, how to avoid it will matter, but after having the site back
that's why I provided referenced info @#17 (the best I could)

PS: I apologize again, but started #27 with an apology to state that I wouldn't agree with you, nothing else, the users having the problem will be thankful of receiving as many support and alternatives as possible, please don't get me the wrong way

Hate forums, there is never a way to express you tone - no offense taken / given :)

The increase of memory does help when running "update.php" way to help reset things. I've "reset" at least 6 sites using the magic that running update.php does. I think that this usually triggers a cache flush and rebuild of the menu but I've never looked into it.

Yet this does fail on many hosted environments due to server based restrictions on the max php memory.

see, now I got your point, and it actually address recovering the broken site
I wasn't aware of that, whenever I ran into it (luckily I haven't in a long while) I solved it procuring a way to manually invoke the menu rebuild, mostly manually inserting the menu router row in the table via phpMyAdmin (it isn't a big deal at all) and then got admin/settings/performance page back to rebuild everything

you approach would be more friendly though

Re #27 above and "should be solved w 6.16..."

I am running 6.16, and installed/enabled CCK and Views on an otherwise working site. AFter about a minute, the browser went blank (as in "plain white screen in browser (Chrome) window"). When I went back to the starting page...the site was dead. I had the teaser portion of my most recent content, and clicking "Administrative" in navigation produced badly mangled screen with "You do not have any administrative items."

Tried removing modules, removing entries from db (e.g., views tables and entries in SYSTEM table)...after an hour simply dropped the db, reinstalled 6.16...copied back the modified theme templates and was running again.

It would be awesome if a rollback/cat recovery, etc. was available....but as others have noted the key to an evolving platform like Drupal is "back up early, back up often." (Or, as we say in rock climbing "Don't climb any farther past your last set anchor than you are willing to fall.")