Magento: General error: 1205 Lock wait timeout exceeded; try restarting transaction

SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction.

This is a lock wait timeout, not a deadlock. The two are different. In a deadlock, two transactions block each other in a circle. MySQL spots this automatically and kills one of them for you. A lock wait timeout is simpler. One transaction waits too long for a lock. Another transaction holds that lock and never releases it.

This usually happens when you run a lot of custom scripts. If you kill those scripts before the database connection closes properly, it leaves an open transaction behind.

How to Check What’s Blocking Your Database

If you can login to MySQL from CLI and run the following command

SHOW PROCESSLIST;

you will see the following output

+-----+---------+-------------------+---------+---------+------+-------+-------------------+-----------+---------------+-----------+
| Id  | User    | Host              | db      | Command | Time | State | Info              | Rows_sent | Rows_examined | Rows_read |
+-----+---------+-------------------+---------+---------+------+-------+-------------------+-----------+---------------+-----------+
| 162 | db_user | 111.11.0.65:21532 | db_name | Sleep   | 3850 |       | NULL              | 0         | 0             | 0         |
| 175 | db_user | 111.11.0.65:27488 | db_name | Sleep   | 3757 |       | NULL              | 0         | 0             | 0         |
| 176 | db_user | 111.11.0.65:32670 | db_name | Sleep   | 3731 |       | NULL              | 0         | 0             | 0         |
| 190 | db_user | 111.11.0.65:47424 | db_name | Sleep   | 3639 |       | NULL              | 0         | 0             | 0         |
| 210 | db_user | 111.11.0.65:56029 | db_name | Sleep   | 3591 |       | NULL              | 0         | 0             | 0         |
| 211 | db_user | 111.11.0.65:59201 | db_name | Sleep   | 3567 |       | NULL              | 0         | 0             | 0         |
| 225 | db_user | 111.11.0.65:2390  | db_name | Sleep   | 3529 |       | NULL              | 0         | 0             | 0         |
| 227 | db_user | 111.11.0.65:10125 | db_name | Sleep   | 3473 |       | NULL              | 0         | 0             | 0         |
| 230 | db_user | 111.11.0.65:18407 | db_name | Sleep   | 3424 |       | NULL              | 0         | 0             | 0         |
| 280 | db_user | 111.11.0.65:35679 | db_name | Sleep   | 3330 |       | NULL              | 0         | 0             | 0         |
| 287 | db_user | 111.11.0.65:57815 | db_name | Sleep   | 1860 |       | NULL              | 0         | 0             | 0         |
| 291 | db_user | 111.11.0.67:20650 | db_name | Sleep   | 188  |       | NULL              | 1         | 0             | 0         |
| 325 | db_user | 111.11.0.65:36618 | db_name | Query   | 0    | NULL  | SHOW PROCESSLIST  | 0         | 0             | 0         |
| 330 | db_user | 111.11.0.75:38717 | db_name | Sleep   | 0    |       | NULL              | 0         | 0             | 0         |
| 426 | db_user | 111.11.0.75:38819 | db_name | Sleep   | 0    |       | NULL              | 61        | 61            | 61        |
+-----+---------+-------------------+---------+---------+------+-------+-------------------+-----------+---------------+-----------+
15 rows in set (0.00 sec)

Most of the rows above are just idle connections sitting in Sleep state. That’s normal. It’s how connection pooling works. The ones worth worrying about are sleeping connections still holding an open transaction. That transaction never committed or rolled back. This usually happens when a script dies mid-run. The PHP process stops, but the database connection stays open. It still holds whatever locks it grabbed.

If you’re not sure which connection is the real problem, don’t kill everything with a long Time value. Check INFORMATION_SCHEMA.INNODB_TRX instead. It shows you which transactions are still genuinely open. That narrows things down to the one or two connections actually holding a lock, not the harmless idle ones.

How to Fix It: Kill the Blocking Connection

Look at row 162 in the example above. Its command is Sleep and its time is 3850 seconds. That one connection is blocking other operations. Kill sleeping connections like this one by one, using the command below.

KILL 162;

Once you have killed all the sleep connections, things should start working as normal again.

Lock wait timeouts tend to come back if you never fix the root cause. Often it’s a script somewhere that isn’t closing its database connections properly. Or it’s a query that runs longer than it should. If you keep seeing this error instead of hitting it once, it’s worth a proper look. Don’t just kill the connection every time it happens.