admin_menu.inc calls menu_router_build() explicitly, causing Duplicate entry error INSERT INTO {menu_router} (race condition)

Just tagging this as a novice issue, since it's pretty simple to patch. Also a more productive way of saying '+1 subscribe'

On larger sites with many modules (cck,views,panels,i18n) I tend to get 100’s of these Duplicate entry in menu_router SQL errors at least once a day.

Eventually I traced it to admin_menu and I have been using the attached patch for a few days now and have not seen any SQL errors.

This patch seems to do the same as what gpk suggested.

Same patch, re-formatted to (hopefully) pass testing

Changing to needs review

Related: #512962: Optimize menu_router_build() / _menu_router_save()

Tracking.

The patch above failed the actual tests (where admin menu checks for the existence of the menu links).

I added the patch on my own site. It applies to 6.x-1.5 fine with an offset, and to 1.6 with no offset. Let's see if it gets rid of the errors...

Unfortunately, the patch does not seem to resolve the issue. Just got a fresh batch of the errors a couple hours after applying it. Backtrace is the same; it happens when the page footer is rendered and _admin_menu_rebuild_links() is called. (I did verify that the call to lock_acquire() is in _admin_menu_rebuild_links()).

I added a call to watchdog() to see whether it is actually acquiring the lock, so next time...

Unfortunately for me ( a real novice with all of this) is on sign-on the site returns a blank screen and from there I can get nowhere. Can I clear the table and let it rebuild. This issue is very debilitating for the work I am trying to accomplish. Do any of the patches improve the situation? I have the lock logic in the menu module but not in the admin_menu where I see that this patch is targeted. For now I am going to uninstall the admin menu. Seems to be an issue all around.

Update of course since I cannot sign-in, I cannot uninstall the admin_menu.

rgdonaldson: To disable a module when you cannot log into your site, you could either use drush or manually disable it in the database:
http://drupal.org/node/157632

If you are getting a blank screen, that sounds like your error reporting to screen is turned off. I'd recommend enabling that during development so you can see what the error messages are:
http://drupal.org/node/158043

So, I've confirmed that the menu rebuild lock is being acquired. However, it looks like about 10% of the time, the lock is somehow insufficient to prevent the race condition. E.g., I have this in the logs from Monday:
1:59 p.m. - lock acquired by admin_menu, not followed by any error messages
2:04 p.m. - lock acquired by admin_menu, not followed by any error messages
2:09 p.m. - lock acquired by admin_menu, not immediately followed by any error messages
2:16 p.m. - lock acquired by admin_menu, followed by
2:17 p.m. - batch of "duplicate entry" messages that backtrace to this function regardless of the lock
2:44 p.m. - lock acquired by admin_menu, not followed by any error messages
2:47 p.m. - lock acquired by admin_menu, not followed by any error messages
3:41 p.m. - lock acquired by admin_menu, not followed by any error messages
etc.

subscribing

subscribing

I enabled devel's query logging this morning and discovered that the menu lock check is getting called scores of times on any given page load, and admin menu is adding about 15 seconds (yes, whole seconds) to my page rendering times. Not sure if it's a symptom of a larger performance issue or not, but I'm now using the alpha for the 3.x branch, which does not have either problem.

xjm: did you apply the patch and then upgrade. Or are you just using the 3.x branch without bothering with the patch? How is the 3.x branch is it for the most part working for "editor" roles that have just basic content creation / editing permissions?

#18: The patch is not necessary for the 3.x branch. I just upgraded the module normally (including running the db update script); it doesn't matter whether you've applied the patch or not because the code is overwritten.

I don't provide access to admin menu to non-administrative roles, so you'd want to test that for yourself in a non-production environment.

Would modifying the insert query in menu.inc to either "INSERT IGNORE ..." or "INSERT REPLACE ..." not work? Or is there some inherent danger in such an approach?

#20: PostgreSQL doesn't support those.

Subscribing.

Subscribing

subscribing

subscribing

I'm sorry, but 6.x-1.x has been superseded by 3.x a long time ago already. The entire, fundamental concept of 1.x was wrong. Therefore, it makes no sense to keep on trying to work around the consequences of an implementation idea that simply doesn't work.

@Sun
Are you endorsing the 3.x Alpha over the 1.x stable release. If so, is the 3.x stable without any core patches. Unless there is a stable 3.x release people are going to continue to use the 1.x release. Thanks for a great module.

Basically yes. While there are also bugs in 3.x due to D6's menu system, those bugs (still being listed on the project page) pertain to the Drupal core menu system only, because 3.x uses nothing else than built-in methods of the core menu system. For that sake, calling it "alpha" is probably wrong, but reality is that anything would be wrong, as long as the core menu system is not fixed.

As long as you do not encounter those bugs, 3.x can be used without any problems.

I have the same issue. we have a pretty rigid "no alpha" policy. The race condition occurs frequently and unable to patch properly. feeling kind of stuck. would be great if we could bump 3.0 status to RC or beta...

subscribing

Subscribing, I seem to have the same issue.

I simply disabled and uninstalled admin_menu. Created simple menu with my most often used links. Happy now!
HobbyBlob.com

Regarding #26 & #27
3.x doesn't working properly at all. Administer disappears from navigation menu, menu disappear from the top very often, and very often when you can't access your admin pages in any way from the panel. You can't even uninstall it properly. And after one year, it's the same. That's why I'm using 1.x
Maybe concept of 1.x was wrong, but at least it's working.
And that's why 15 times more people using 1.x, instead of 3.x (150k and 16k).

subscribing

no patch works. 3.x is alpha (REALLY alpha) why is this close "won't fix"???

I also ended up disabling admin_menu ... switched over to using admin instead and I've not encountered this error since

subscribing

See #1189532: function _admin_menu_rebuild_links() calls menu_router_build() which may bypass the locking mechanism. Yay?