menu_router table truncated and site goes down: Transaction or Lock required for D6

Nevertheless, for D6 solution it would be hard to follow #238760: menu_router table truncated and site goes down which in addition is targeting D7.
So, I will make this comment here replying many cites from that discussion.

In Drupal 6.3 I set timeout to 200, but it always can be repeated trying to enable a bunch of modules at once.
Current workarounds:

• be gentle and enable few modules at a time
• avoiding such a php solution I prefer to manually insert the row which makes admin/settings/performance available and clean all catched info from there
• disabling all cache with DisableCache for development (just in case I get a timeout enabling many modules at a time)

Is there a reason why this bug moved to D7?
I think it should be there in one of the next 6.x

Please let me know if I'm wrong

Optalgin, usually bugs are fixed in the development branch then backported to D6 (also there are currently more people looking at issues for D7 core). There are exceptions, and if this really does require db_lock_table() it might be one of them, but it's worth trying to keep both branches consistent unless there's a particular reason not to.

I don't agree. If this issue should be posted to the D7 branch then it should stand as an independent issue probably referencing this one. But this IS a D6 issue. And when it get fixed in D7 it will remain pending to be backported to D6.
It would be totally incorrect that someone review the D6 branch and see no critical bug on it, thus it would be declared cleared of issues.

Table locks are out in D6, so I think just shortening the window is a good start.

Shortening the window is a start (maybe a good one) but definitively NOT the solution because the site still may go down.

I don't mind using a table lock for D6 if we did not officially remove LOCK TABLES from the requirements (and for sites where the lock fails they are not any worse off than now).

I agree. If there are tons of docs stating the requirements then it can be used. Nevertheless, transactions are the answer.
But if it can't be done with transaction, then trying the lock will do for many sites, taking into account that the lock might fail on some hostings and then the code should be try-catched falling back to the "minimal window"-"race condition" fashion for those servers not having the lock permissions; it will be then a requirement violation, not a Drupal's bug.

since D7 will almost certainly support transactions, I think the issue is really how do we get a stop-gap for D6.

Bad news if it's "almost", but again, when solved the problem in D7 this will still be a D6 active issue.

will transaction-safe database engines (ie InnoDB on MySQL) will be a strong requirement of Drupal 7? Let me doubt it.

Is not a bad idea. Come on, progress is nocking the door; And BTW transaction is an old concept and requirement on DBs.

I wanted to test the module_builder for 6.x, so I attempted to install it and it crashed my site [...] (sure it was a -dev version and I was merely on my local test environment, but modules should fail to install more gracefully than knocking out the rest of the site, I think).

Don't blame the module. Certantly it was just trying to create a bunch of tables and timed out.
How many modules did you tryied to enable at the same time?

Because we don't check this requirement anymore, the db_lock() operation will throw errors when the database user does not have the necessary permission. This is not acceptable (especially for the D6 part of this bug).

Isn't this catcheabe at all?
Catching it can allow to fallback to non-locking fashion minimizing the critical window.

Committed #33 to Drupal 6. RTBC for Drupal 7, and then feel free to come up with something else from there in Drupal 7.

To which version of D6?
This is why it shouldn't be changed to D7 branch.
This issue isn't fixed for Drupal 6.3

Yes- this will be in the Drupal 6.3 release - it was already committed to that branch.

But it still happening on Drupal 6.3 when trying to enable several modules at the same time.

Version: 7.x-dev » 6.x-dev
I committed this to CVS HEAD but I believe this will need to be backported to Drupal 6.

You should stop playing around with D6 -> D7 and D7 -> D6 is an issue of both with different solution, but even if it would be the same solution it must be known as 2 different issues. If the intention is to discuss the same issue for both cases then post in D7 issue that the discussion will take place in D6 or vice-versa. But one of the branches might achieve the solution while the other one might still open or maybe reopened.

I installed the 6.x-dev version and confirmed that the changes in #33 are in the source but this has still not fixed the problem for me. I'm still getting lots of these errors on page loads. (not every load but it seems to happened randomly.)

Obviously reducing the window is a starting point for optimization, but not a solution at all.
I think a transaction is required even if it would have to be provided by some new patch code.
Is asking too much to say "transaction" when talking about DBs?

Now that I'm reading back through the full issue here, I'm thinking that it is not the same thing.

The same issue it is indeed!
Yes, once the menu_route table is empty and then filled in a loop the timeout breaks the loop and there is a menu_route half filled, when the menu_route is rebuilt for second chance then it finds a lot of duplicated ids.
Once again: Transaction is required.

@scottrigby - this appears to be the opposite problem. The router is not cleared during the rebuild. There needs to be a separate issue for this, since I think it's a different bug you're seeing and in #58.

Disagree. It is the same issue. Just the timeout happened in the middle of the loop and after that a rebuild was attempted. That's why the duplicate ids and that's why it get fixed anyway.

Sorry for the long post, but I have not time to recreate it by pieces.
I think this can be a quick reference to that discussion which turned to D7 (#238760: menu_router table truncated and site goes down)

resuming a list of related issues (several duplicated ones, all of them seems to be deviated to #238760 but that one is now just for D7, at least I hope they stop jumping from D6 to D7 back and forward):
#238760: menu_router table truncated and site goes down
#246653: Duplicate entry in menu_router: Different symptoms, same issue
#248739: Duplicate entry errors - lots of them

Nevertheless I think the D7 issue should be concentrated at #251792: Implement a locking framework for long operations while leaving other issues be D6

Other related issues:
#249185: Concurrency problem with variable caching leading to cache inconsistency

In reply to http://drupal.org/node/246653#comment-947182
(please don't jump issues from 6.x to 7.x back and forward over and over, because they won't be traceable and this is an issue tracker)

Yes it is the same issue.
Lets see
if you rebuild the menu with devel module and the problem goes off (if you ever get with this issue it will be appearing over and over almost for sure) then we are talking about the same issue.
Different symptoms, same issue
Once the menu fail to be rebuilt different symptoms might come up.
1- site goes down / administrative task are unavailable / some URLs are unavailable
2- site keeps complaining about duplicated keys in menu_router table

The cause is a timeout or whatever might interrupt a non-Transactional manipulation of the data (when I run manual test looking for robustness I suddenly shutdown the MySQL server), this is (IMO) a critical flaw of Drupal 6 (don't know what about 5 but I think it has some sort of table locking)
1- If the menu doesn't get rebuilt then the menu_router table might be almost empty causing the unavailability of the site
2- If the menu get partial rebuilt but isn't flagged as totally rebuilt the site might be usable and in further request it will attempt to rebuild it, but as it is partially built then it will complain about duplicated keys.

I don't think this is duplicate - this is a totally different (in fact opposite) problem from #238760

Please, this issue was originally posted for 6.x
if this isn't a duplicated, then find, mark it as such, but don't change it to next generation of Drupal, the issue is present in 6.x and as such must remain until marked as fixed, won't fix, or whatever. Once the issue is marked maybe as "won't fix" then incoming issues might be marked targeting 7.x, but for now, this issue is present in 6.x, it's a major issue and as such deserves to be answered (in the worse case as "won't fix")
I won't mark it as duplicated again because you don't agree, but I'm returning it to the 6.x where it belongs to.

See what happened on #238760: menu_router table truncated and site goes down jumping to 6.x and to 7.x over and over, it's not traceable.
Please read #289618: menu_router table truncated and site goes down: Transaction or Lock required for D6 again and try to agree with me why this issue must be kept on both 6.x and 7.x but as different issues (for tracking purpose) and maybe both referencing a unique discussion until they split up (sooner or later one of them will be marked as fixed or won't fix while the other one will not)

- being afraid to use D6 on production: #254616: SIte corrupted with no administrative blocks any more after going to admin/build/modules
- another one bites the dust: #248286: Module Development and Potential Vulnerability -- {menu_router} table can be erased.

in reply to http://drupal.org/node/246653#comment-950307

the process is that bugs are fixed in the newest version before backporting. The menu code in 7.x is very much the same as 6.x, so whatever bug is present should be addresed in 7.x first.

Well, I disagree with pointing every issue to D7 because there are proposed and tested patches for D6 (follow the references in my previous comment) and then the issue is changed back and forward every time someone think has the solution for D6 and later someone change it back to D7 because the patch is rather a improvement but not a solution.

What I'm having a difficult time understanding is that there is a query to delete all entries from {menu_router} before any inserts are attempted. So, is that deletion query failing for some reason?

The deletion always succeed. The insertion is what fails because of timeout. Now, if the menu is half built and some change (module enabling/disabling, accessing modules pages I think causes it also, and other situations) triggers the rebuild menu task, then there will be duplicate entries, of course. Now I don't remember when I looked into the code, but for some reason, rebuilding the menu with devel most of the time succeeds, deleting the whole menu_router table and recreating it again, but in other situations a rebuild is attempted without deleting the table first.
There are proposed patches that improve this awful situation in several ways without providing a definitive solution:
- the first one reorders the code so the computation is done first and the delete is near the insertion (originally the deletion is first, then computation and later an insertion loop, the time window for failing such task is huge)
- the second one remove the deletion attempt and uses ALTER instead of insert (valid only when menu is augmented, wrong otherwise)

please, follow the pointed issues on my previous comment

The problem continues arising (http://drupal.org/node/291056 "Admin Module page won't load and produces confusing error message")
So, this is the fast workaround for those stocked out of the site

- Create a repair.php file with the following code

  require_once './includes/bootstrap.inc';
  drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  menu_rebuild();

- upload the file to the server
- access the page and wait
- if there is no timeout it would do the trick.
- if there is a timeout, go to php.ini and increase the max_execution_time and increase it's value (up to 600 if needed, even more if it's a slow PC, later you can tune this to your needs)

What you are describing in this particular issue looks like something different (a timeout that can lead to menu not being completely rebuilt), and should *not* lead to duplicate entry errors.

That was what I thought at first, but they always come in pairs... why?

For those trying to find out which is the real state of this issue I repeat it's discussion is at #238760
I replied there because must people won't read an issue marked as "duplicate" as it seems this issue will remain.
But those reading above that this issue is patched already in 6.3 I say IMO it isn't.
So I repeat here what I said in #238760

With that patch, duplicate entry errors on menu_router can *only* happen when two requests try to concurrently rebuild the menu table and fall inside the (shorter) window of vulnerability.

a shorter window of vulnerability is still a window and thus a vulnerability
How many administrators are allowed by Drupal?
If the answer is "only 1" then we can rely in a shortened window and a workaround documentation for exceptional cases.
But two or more administrators might be doing different stuff and thus causing a race condition.

The process here, for Drupal core, is to fix issues affecting several branches in the *same* issue ticket.

That goes fine for the discussion about the issue as I stated on that issue of mine, but I also think that another opened ticked should exist to avoid forgetting for instance to backport it or whatever would be the final answer to the other branch.
That's why I don't agree with

Having several separate tickets for the same issue is the best way to forget to fix an issue in one of the branches.

but if it's that the way you go...

Also, our process involves fixing the issue in the development branch (today Drupal-7), before backporting in order to always have an up-to-date development branch.

How do you keep track of what needs to be backported or fixed in older versions if all the issues are marked as duplicates in that branch.
OTOH, think I'm a newbie to Drupal (which is not far from the truth, think I'm another newbie) and I find such problem with Drupal, I go to the issue tracker and search the branch 6.x to see if some body saw that too.
What do I find then?
Only duplicates.
Why?
Because patches, fixes, and everything else is in D7 branch. Which I won't look for because I'm not a HEAD developer.

Two things:
- I strongly believe that being the same issue should be discussed one place, but having to possible different final solutions must be different issues. Once the fix is done for 7.x there will be a D6 issue pending for backporting or whatever it's own final solution would be (even a "don't fix")
- The issue wasn't solved with neither of those patches. I've being working with Drupal 6.3

Do you work with two browser. I guess you do, so do I. Now you know how I run into this race condition from time to time. Also, when working on any system that uses database one test realized before starting working is support for suddenly database server shutdown. Drupal 6.3 doesn't pass this test because the lack of transaction and locking.

The process is not something you can or should discuss, at least not in the middle of an issue ticket.

I'm really sorry. I wasn't aware who had the truth. I just said what I thought was common sense. Look above this thread and tell me if this tracking system tells you for sure whether this is an issue present in 7.x, 6.x or both.
I always saw the issue tracking system as a tool which has that brief view on top letting me know quick and without reading the whole discussion the status of the branches. Allowing me also to query the health of a particular branch. If I find a cleared branch there is nothing more to talk about it: it's bug free! tested and approved by the community. Is that right?

I'm marking this one as a duplicate. Please don't reopen. If your problem is the same as #238760, it should be discussed there, regardless of the current version of that ticket.

My issue starts stating that is the same issue for a different branch, I also explain how D6 has patches improving it but not solving it. I also state that the discussion should be followed here. I made every issue/forum I found with the same or similar issue be aware of this discussion.
But I tell you again there is an issue in D6 which doesn't appear opened (for 6.3 I'm talking)
How ever searches the tracking system will find duplicated and the "original" ones are for D7. Thus, the issue will be opened over and over for D6, and other people will redirect them here and explain them why it's targeting D7.
Ok, this issue might be. But is a wrong policy for treating an issue queue. Same issues will keep showing up until people can search and found it reported, in the correct branch and with it's correct status, nobody will be hurt if the issues are different for live cycle and all of them point where the discussion must be.