ispconfig 3.0.3.1 with nginx - updates give "Error while sending INIT_DB packet"

[talkingnews]

I seem to be getting "stuck" jobs now, all I'm doing it trying to add an nginx rule. That job processes and nginx updates OK, but it's still showing as a stuck job and attempts to do the same thing every minute. In other words, if I change a site config, then 10 mins later manually edit that file (just to test!), 1 minute later it will be back to how it was in ISPC.

Thanks to this post I can now remove the stuck job, but it's happening all the time. The only other change I've made is to change all the tables on all my db's to be InnoDB, as recommended...well, everywhere now, as it's the default. All other aspects of ispconfig and my site work well.

Here's the ISPC error log:

PHP Warning:  Error while sending INIT_DB packet. PID=13096 in /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php on line 104
PHP Stack trace:
PHP   1. {main}() /usr/local/ispconfig/server/server.php:0
PHP   2. modules->processDatalog() /usr/local/ispconfig/server/server.php:162
PHP   3. db->query() /usr/local/ispconfig/server/lib/classes/modules.inc.php:228
PHP   4. mysql_select_db() /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php:104
nginx: [warn] conflicting server name "localhost" on 0.0.0.0:80, ignored
PHP Warning:  Error while sending INIT_DB packet. PID=13130 in /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php on line 104
PHP Stack trace:
PHP   1. {main}() /usr/local/ispconfig/server/server.php:0
PHP   2. modules->processDatalog() /usr/local/ispconfig/server/server.php:162
PHP   3. db->query() /usr/local/ispconfig/server/lib/classes/modules.inc.php:228
PHP   4. mysql_select_db() /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php:104
nginx: [warn] conflicting server name "localhost" on 0.0.0.0:80, ignored
PHP Warning:  Error while sending INIT_DB packet. PID=13165 in /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php on line 104
PHP Stack trace:
PHP   1. {main}() /usr/local/ispconfig/server/server.php:0
PHP   2. modules->processDatalog() /usr/local/ispconfig/server/server.php:162
PHP   3. db->query() /usr/local/ispconfig/server/lib/classes/modules.inc.php:228
PHP   4. mysql_select_db() /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php:104
nginx: [warn] conflicting server name "localhost" on 0.0.0.0:80, ignored
PHP Warning:  Error while sending INIT_DB packet. PID=13218 in /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php on line 104
PHP Stack trace:

and so on.

[till]

You should change the ispconfig databases back to myisam.

By the way, who recommended you to change the ispconfig database dbispconfig to innodb when the ispconfig installer explicitely creates them as myisam (see sql dump)?

[talkingnews]

Originally Posted by till

You should change the ispconfig databases back to myisam.

Tried that - it was the same. I remembered what it was now - the update process takes a while, and I'd set the mysql conf to timeout in less than 5 seconds, as recommended by mysqltuner. I changed it to 12 and it worked fine.

Originally Posted by till

By the way, who recommended you to change the ispconfig database dbispconfig to innodb when the ispconfig installer explicitely creates them as myisam (see sql dump)?

I was just having trouble with an incredibly slow Wordpress install, and started changing tables from there, then I changed Zen Cart, then I changed phpbb - with each one, I definitely noticed the 25% speed increase that people were suggesting that InnoDB should give. And with the extra reliability and data integrity of innodb and with it now being the default, I just thought I might as well do all the remaining tables which were myisam.

I also thought that scripts were agnostic as far as the table engine being used? I've not come across any script which cared whether it was myISAM or InnoDB before, only an old one which used MyISAM indexes.

[till]

Innodb is indeed faster when it comes to complex queries that use a lot of joins, but on the other side innodb uses a lot more ram. As ISPconfig dont use complex queries and does not require any of the innodb features, so it does not benefit from innodb and we decided to keep the RAM for the applications instead of wasting it for the controlpanel.

I also thought that scripts were agnostic as far as the table engine being used? I've not come across any script which cared whether it was myISAM or InnoDB before, only an old one which used MyISAM indexes.

Thats almost always the case, but in some scenarios the engins seem to differ when it comes to inserting data into the table. I experienced that a operation might succeeed with myisam while it failed with innodb, maybe myisam is a bit more fault tolerant.