Jeżeli pojawia się taki komunikat, to najprawdopodobniej problem leży po stronie zmiennej wait_timeout. Wartość jej zależy od typu klienta łączącego się do bazy – albo pobierana jest wartość z globalnej zmiennej wait_timeout, ablo z interactive_timeout.
Dla przykładu – FreeBSD, MySQL-5.0.92, połączenie z użyciem klienta mysql:
thscd@arsenic:~ $ mysql mysql> SHOW VARIABLES LIKE 'wait_timeout'; mysql> SHOW GLOBAL VARIABLES LIKE 'wait_timeout'; mysql> SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';
daje odpowiednio wartości:
wait_timeout 28800 wait_timeout 60 interactive_timeout 28800
Natomiast wywołane w postaci skryptu:
#!/bin/sh mysql -e "SHOW VARIABLES LIKE 'wait_timeout';" mysql -e "SHOW GLOBAL VARIABLES LIKE 'wait_timeout';" mysql -e "SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';"
da już inny wynik:
wait_timeout 60 wait_timeout 60 interactive_timeout 28800
… to samo, z użyciem np. Pythona (MySQLdb):
tlhscd@arsenic:~ $ ./test.py ('wait_timeout', '60') ('wait_timeout', '60') ('interactive_timeout', '28800')
Jeżeli nie możemy zmienić globalnej wartości, zawsze można ustawiać ją na poziomie sesji, zaraz po ustanowieniu połączenia, na przykład:
SET SESSION wait_timeout=300;
… i jak widać, działa:
tlhscd@arsenic:~ $ ./test.py ('wait_timeout', '300') ('wait_timeout', '60') ('interactive_timeout', '28800')