I get the following error (or something very close to it) when attempting to load many admin pages using Drupal 7.0:

PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: DELETE FROM {cache_update} WHERE (cid = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => update_project_projects ) in _update_cache_clear() (line 829 of /[path_to_drupal]/modules/update/update.module).

I'm currently unable to view admin/modules, admin/reports, admin/reports/*, etc, etc with or without the overlay.

It's a very small site with a close-to-base install.

Modules (other than core):

  • Views
  • Pathauto
  • Token
  • Auto Nodetitle
  • Ctools
  • Link
  • Login Toboggan

I'm on a Media Temple GV hosting plan which has been, admittedly, a bit sluggish at times for Drupal. I'm not seeing this error on other sites hosted on the same plan, however.

This is somewhat similar to #963276: PDOException cache error, but not identical.

Comments

scottrouse’s picture

Status: Active » Closed (cannot reproduce)

My host, Media Temple, admitted that there was a "bad" MySQL user in the same container as my MySQL processes were running. They removed the user, and my problems appear to have been resolved.

Rayrunner’s picture

I also am on Media Temple and I am seeing the exact same problem. I suspected that the connection time between web server and the mysql server was taking to long but can not confim it.

sstoft’s picture

I am also on Media Temple, an I've had this identical error for 12 hours. March 17-18, 2011.

scottrouse’s picture

FWIW, ditching Media Temple helped my Drupal site performance greatly.

ctruman’s picture

This is an issue with Drupal not Media Temple

jim22’s picture

Same error. I also use Media Temple. It's only affecting this one Drupal 7 site, though.

I've tried a bunch of solutions with no success.

duoming’s picture

I'm experiencing a similar problem, also on Media Temple. Specifically, the error occurs when trying to enable or disable the Google Analytics module.

mmcdermott’s picture

I've been having this problem intermittently when working for a client on MediaTemple as well.

I'm getting it on almost everything I try to do. Sometimes Chrome will load things okay, but Firefox and Opera are extremely slow and display that error when pages finally do load. It doesn't seem to be associated with any particular module or action in my case.

visum’s picture

I am also experiencing this problem and am currently working with MT support to resolve it. Have any of you uncovered any leads to resolving this?

jackfoust’s picture

Also having same issue with a mediatemple gs. Only have the error and page timeouts though when I set journalcrunch as default theme. Very strange. No modules except core.

PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: SELECT 1 AS expression FROM {variable} variable WHERE ( (name = :db_condition_placeholder_0) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => isFirstNoStickyNode ) in variable_set() (line 805 of /nfs/c08/h03/mnt/xxxxxx/domains/xxxxxx.com/html/includes/bootstrap.inc).
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in theme_get_registry() (line 249 of /nfs/c08/h03/mnt/xxxxxx/domains/xxxxxx.com/html/includes/theme.inc).

jim22’s picture

Having this problem on another Drupal 7.2 site on Media Temple (gs). this is what support said;

"Your site is hanging on one of your insert queries. The query is so big that I'm not going to clutter this ticket with it, but I'd like you to take a look at the query which I've pasted in a text file on your (gs) Grid Server under ~/data/query.txt.

Do you have any idea why your system would be posting a query like that each time a person loads your index page? I cannot imagine that inserting this much data into the database on each page load is really what you want. Take a look and let me know if there's anything we can do to help."

This is on a 7.2 install with: CKeditor, Ctools, Views, Views Slideshow, Token, Webform, jcarousel, Link, Menu Attributes, Backup Migrate, PathAuto.

This is beyond my knowledge.

jim22’s picture

Oh, forgot. I am also getting this error and can't figure out why. I've deleted all whitespace before opening php tags. There are no ending php tags at end of php files.

Warning: Cannot modify header information - headers already sent by (output started at .../domains/example.com/html/includes/common.inc:2562) in drupal_send_headers() (line 1039 of .../domains/example.com/html/includes/bootstrap.inc).

The page loads extremely slow and then it's displaying the html page twice (one on top of another in the browser).

visum’s picture

Update -- To help find the problem, MT gave my client a trial of the MySQL container add-on, which resolved the problem for my client. However, the additional cost per month makes an already more expensive hosting service just unreasonable (in my opinion), so we moved the site to another host. My conclusion is that MT's DB set-up is simply not Drupal 7 friendly. Or to look at it another way, Drupal 7 is too DB intensive for MT's set-up.

If there is actually a Drupal solution to this problem, I'd still be interested to know it.

ahabman’s picture

Media Temple Grid Server is causing this similar issue for me. D7 very basic site.

General error: 1205 Lock wait timeout exceeded; try restarting transaction menu_expanded in variable_set() line 805 bootstrap.inc

phonographstudio’s picture

On Media Temple (gs), this error seems to occur from time to time when the cache tables gets too big.

Use phpMyAdmin from your (mt) account center and truncate all tables starting by cache_ from the database.

This seems to fix the problem. (at least for me) ;)

It is probably be a good idea to backup your DB before doing that!

aydos’s picture

drupal 7.8 dont solve the problem... (even there exist three issues about cache, one prevent the cache tables getting too big).
mt said that its related to drupal cache system (on db), they will try to solve (without giving a timeframe)

Starlight_Design’s picture

Version: 7.0 » 7.7

Using 7.7 here and it's wonderful to be so busy and then can't access pages, so BIG THANKS to phonographstudio for your quick fix, though I suspected the cache anyway. I did not want to use MT at all, especially when their knowledgebase says they only support the one-click installation of drupal 3 or something, but then they put in some sort of patch from php4 to php5, so I'm using them anyway. There are much better hosts out there who are fully drupal capable, for good prices, too!

CarbonPig’s picture

Version: 7.7 » 7.8

Subscribe - I am also using Media Temple's grid service for a new site I'm developing.

I got an PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; that point to line 203 of the sessions.inc file.

I truncated (empty) the sessions table using php myadmin and this seemed to resolve the problem at least temporarily.

Truncating the cache tables did not help.

Thanks,

CarbonPig

aydos’s picture

while they are searching and fixing an unknown bug on shared mysql server i choose another hosting firm and could run drupal 7 with a mysql server which i installed...

hudson.graham’s picture

I am also with MT and came up against this issue today...

I installed the theme Corolla 7.x-2.2 and activated it as the default theme without installing the needed subtheme Adaptivetheme 7.x-2.x. This created some errors about file paths and I quickly realise what I had done and installed the subtheme ASAP. This appeared to have worked fine and a little while later I ran into the "1205 Lock wait timeout exceeded" issue and spent a few hours trying to resolve the problem... Backtracking my steps (setting up Drupal 7.8 on MT), I realised that I must have corrupted the Database when I made this mistake. So, I dropped all my db tables and reinstalled Drupal with the install.php file again and it all works sweet now.

This doesn't appear to be a MT issue, but more a corruption of the db issue.
Hope this helps someone out.

h

UPDATE: I set-up a second site today and did it all in the correct order and when I was playing with the settings of the skin (Sky 7.x-2.2) I got the "1205 Lock wait timeout exceeded" error... Maybe this is MT???

OldCode101’s picture

I have been getting this error for a couple days now. Media Temple (GS)

REMUU’s picture

This error has occured for me on two separate installs. This error first started to appear for me after i tried to install Zen. It has continued to appear since then, even after uninstalling Zen. Currently working on Drupal 7.8. Contributed Modules: Devel, References. Mediatemple (GS)

When I clear all the caches using PHPmyadmin, it acts as a temporary fix and I am able to access the site, but eventually it happens again.

I also noticed that when I tried to "Clear all caches" from the "Performance" page within my drupal site, it took much longer than expected. I'm assuming this has to do with the fact that the cache tables get super large very quickly, but I'm wondering if there is something wrong with the cache clearing mechanism in drupal and the way it works with mediatemple?

mt_Drew’s picture

Hi everyone. I work at (mt) Media Temple. Our engineers recognize that this is an issue & have provided a fix that is obtainable in 2 ways. The first & recommended method is:

1) Back up your data
2) Remove Drupal from your account
3) Re-install Drupal using the updated 1-click installation
4) Import your data

The second method isn't necessarily the BEST fix, but it has been tested. Note: this is not supported by (mt).

1) Dump the whole DB
2) Dump the variables table. "mysqldump -uUser -p db1234_drupal variable > db1234_drupal.variable.sql
3) Change the 'engine=INNODB' to 'engine=MyISAM'
3. Reimport your table

*Statements like these below, will now work:
MySQL thread id 323367, query id 16367943 205.186.184.26 db94731_blair statistics
SELECT 1 AS expression
FROM
variable variable
WHERE ( (name = 'icl_manager_role') ) FOR UPDATE

-(mt) Sara

scottrouse’s picture

Sara,

Thanks for chiming in here. I really appreciate your participation in this thread.

I am curious, however, about the underlying problem. The "one-click install" option provided by a number of hosting companies isn't always a great option since users sometimes loose some control over updates or management of their codebase. What is it that (mt)'s one-click install does differently from the standard Drupal installation procedure and why is it necessary with (mt)'s hosting configuration?

Thanks,
Scott

Melissamcewen’s picture

My site was created from a one click install and is having this issue. Totally bizarre issue and seems to only be MT.

tedchwang’s picture

I have the same problem with MediaTemple gs. My installation was made with MT's 1-click (Drupal version 7.8), then upgraded with drush to version 7.10.

Truncating the sessions table resolved the problem for me a couple of times. But it doesn't do the trick anymore. Clearing the cache doesn't help, either.

redowie’s picture

I had the same issues. session and cache table truncation was working but things were slower than desirable. I upgraded to the MySQL container on MT's GS service. $20+ a month and it made a big difference.

Guessing MT's shared DBs are pretty heavily trafficked by the number of threads here and Google search results that show this error in the wild.

adamfairhead’s picture

Been wrestling with this problem all day. The solution was to turn every SQL table's engine to MyISAM. I hope that saves someone hours of stress.

itaces’s picture

Version: 7.8 » 7.12
Component: cache system » user.module

Same... have MediaTemple GS. Getting the error but when changing user permissions. In my case... affected table was the role_permissions.

Used the 2nd fix that MediaTemple sara person recommended. (added some clarifying steps)

1) Dumped the whole database.
2) Dump the variables table. "mysqldump -username -p db1234_drupal badtable > db1234_drupal.variable.sql
3) Change the 'engine=INNODB' to 'engine=MyISAM' (edit the text in the file you download)
3.5) Drop the badtable
4) Reimport your table

Error went away.

sumogray’s picture

Wow. Just got stamped on by this too.

Thanks for the solution, wish I'd found this thread 8 hours and 3 core installs ago.

Is this now stable, or are we going to run into more problems?

brian.sanchez’s picture

could somoneone explain how to delete this comment? I was wrong, but I want to delete it, I couldn't find a way to remove it.

SilviaT’s picture

Maybe this is related http://drupal.org/node/1369332 ?

justingeeslin’s picture

#23 (2nd Fix) does it for me. Thanks mt_Drew!

brody’s picture

I am having the same problem With (MediaTemple.com)

PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: SELECT 1 AS expression FROM {variable} variable WHERE ( (name = :db_condition_placeholder_0) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => cron_last ) in variable_set() (line 999 of /nfs/c10/h02/mnt/xxxxxxxxx/domains/xxxxxxxxx.com/html/includes/bootstrap.inc).

this is a cron problem..

My cron is running wild, an running every second

brody’s picture

a lot of $10 a month web hosts work a lot better than the Bull**** media temple

brody’s picture

Version: 7.12 » 7.16
Component: user.module » other

To fix this go to your database table xxxx_variable and change Type from innodb To MyISAM

youssefr’s picture

I have same issue here; Media Temple always offers trial of the MySQL container. When you signup it is an additional $20 to the GS cost. .!!! Definitely, I am leaving Media Temple to find another host. I am afraid that "one-click install" is the right solution for me.
Thanks.

studio-days’s picture

#29 worked for me!

I was getting the 1205 Lock Wait Timeout Exceeded error when I tried creating a new Content Type, using Drupal 7.15 on Media Temple GS.

I actually hate Media Temple. And love you guys!

Fr0s7’s picture

#23 / #29 did not work for me. I also truncated all of the cache tables with no effect. I have done nothing other than install Drupal and create 1 content type. My site has become completely unresponsive, returning 504 Gateway Time-out errors in the browser. I get the same slow response times when using Drush. Even drush cc all takes several minutes, and then fails.

I have never had this problem with any other host. For $20 a month, I expected a lot more from MediaTemple.

yuriy.babenko’s picture

For anyone who comes across this issue in the future: avoid Media Temple at all costs. Their database servers are in a physically different location from their web hosts, so all queries take ten times longer than they should. For a query-intensive application like Drupal, this is simply an unacceptable deal breaker. Move the site to a different host and you'll see a huge, instant speed increase.

jeantyler615’s picture

I am getting the same error:
PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: SELECT 1 AS expression FROM {cache_update} cache_update WHERE ( (cid = :db_condition_placeholder_0) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => update_project_projects ) in _update_cache_set() (line 785 of /nfs/c03/h02/mnt/xxx/domains/xxx/html/modules/update/update.module)

I am not technical, How do I do #2.

1) Dumped the whole database.
2) Dump the variables table. "mysqldump -username -p db1234_drupal badtable > db1234_drupal.variable.sql
3) Change the 'engine=INNODB' to 'engine=MyISAM' (edit the text in the file you download)
3.5) Drop the badtable
4) Reimport your table

I think it is a problem with a lot of users, just logged onto the chat an it is busy. I have worked many days to get my site up, and now this error!!

jeantyler615’s picture

something strange, I changed the permissions on the settings.php to 777 and it unlocked the site and error.

crosstopher’s picture

#29: yep.

I was getting these same ridiculous DB slow downs on MediaTemple gridserver, with Drupal 7.16.

Dumped the entire DB to an .sql file,
Did a find and replace "engine=INNODB" -> "engine=MyISAM" and imported this .sql back to a new DB.
Switched 'settings.php' to point to the new database and the whole site is way, way quicker.

mattf’s picture

Same thing here too! Except in my case: weeks wasted. I had the database restored to "known good points" several times (ha!) at MY cost, yet. Baffling performance issues, sluggishness, unexplainable errors, completely random crashes, and MT technicians suggesting that it could be related to "the way Safari parses PHP" and trying to upsell me to the next level of server.

And yet, easily resolved when I followed the simple recipe provided by Drupal Brothers & Sisters in arms. In 20 minutes. How I wish I'd found you sooner, and therein lies the lesson for me: when experiencing difficulty IMMEDIATELY check drupal.org.

SO: Media Temple, since we know you're watching this thread, at least intermittently, and have known for OVER A YEAR about this problem, WHY is it not yet resolved?

Because it seems to me that a failure to resolve the problem caused by MT's "one-click install" in a year (while blithely selling it all the while, and failing to mention it as a possibility in ANY of my service phone calls) constitutes either gross negligence or (more darkly) grounds for a lawsuit for any users who were encouraged to upgrade because they "needed" the next level of plan. Don't ya think?

joshuautley’s picture

Just my two cents...

I experienced a very similar error with the Calendar module D7.22 install. I encountered the error after updating an unrelated module. So, I Googled the error and ended up here. Because I'm hosted with Rackspace and not MT I thought when in doubt Clear All Caches.

That did the trick and the Calendar page no longer throws an error.

So, my advice... if you have not cleared all your caches try it. If that doesn't work - no happy dance.

kalidasan’s picture

Clearing all my caches solved this issue :)

Thanks joshuautley.

joshuautley’s picture

@ #46 Glad it worked for you too. (=

syodash’s picture

same problem

Safallia Joseph’s picture

Try restarting webserver. That solved the issue for me.