Yes that is what I meant Mikael. In the server on demo.openmeetings.de those config variables are exactly the same: mysql> SHOW GLOBAL VARIABLES LIKE "wait_timeout"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | wait_timeout | 28800 | +---------------+-------+ 1 row in set (0.00 sec)
mysql> SHOW VARIABLES LIKE "wait_timeout"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | wait_timeout | 28800 | +---------------+-------+ 1 row in set (0.01 sec) mysql> Another reason might be that the host in general is not available. You could for example test this by doing a (nasty) small ping script that runs "demon-like". For example: nohup ping -c 100000000000000 web.de & it will write all ping results to a file called nohup.out. And you can check the output in real-time using: tail -f nohup.out with some more "shell kung-fu" I guess you could also add the date part in front of every ping result. Then you let run the script overnight. And tomorrow morning when you see in your openmeetings log file => there was a db connection lost, you see in the openmeetings log what time exactly the connection lost was And then you check the output of your ping protocol in the nohup.out if there was any host issue (especially around that date/time of course). Sebastian 2012/12/13 Mikael Kurula <alcar...@gmail.com> > 2880 -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
