ISPConfig 3.0.1.4 causes Apache to have too many open files

[clixclix]

Hi,
I'm having the same problem on a fresh Debian 5.0.3 64bit server, with ISPConfig 3.0.1.4 installed as "slave" server.

Here is an example of the error I get, trying to add a client:

Warning: listform_actions::include(/usr/local/ispconfig/interface/lib/lang/en.lng)[listform-actions.include]: 
failed to open stream: Too many open files in /usr/local/ispconfig/interface/lib/classes/listform_actions.inc.php on line 143

Some more info:

/home/admin# lsof |wc -l
6192

/home/admin# ps aux | grep php
root      7593  0.0  0.0   5160   784 pts/0    S+   23:02   0:00 grep php

I get the same "Too many open files in ..." error randomly across other sections.


Also, any website creation done from the master panel to the slave server remains forever in the monitor jobqueue of the master.... maybe it's related.

The master server works correctly on itself.

[till]

I get the same "Too many open files in ..." error randomly across other sections.

Ok, but if thats a slave, then you can not run a interface there and you can not get this error message on the slave. Are you really sure that this error message was not shown on the master thats runs the interface?

Also, any website creation done from the master panel to the slave server remains forever in the monitor jobqueue of the master.... maybe it's related.

Thats most likely not related. Its just a mysql permission problem. Make sure that the master and slave are able to resolve the hostnames of each other e.g. by adding them in bost /tc/hosts files. otherwise the mysql authentication will fail and no data gets replicated.

[clixclix]

Originally Posted by till

Ok, but if thats a slave, then you can not run a interface there and you can not get this error message on the slave. Are you really sure that this error message was not shown on the master thats runs the interface?

Probably the interface is there because I first installed ISPConfig3 in normal mode, then I deleted the ispconfig database and reinstalled all in expert mode in order to let it work as slave.
Should I remove everything and reinstall everything from scratch?
Should I just remove the admin interface application on slave? How can I do that?

Originally Posted by till

Thats most likely not related. Its just a mysql permission problem. Make sure that the master and slave are able to resolve the hostnames of each other e.g. by adding them in bost /tc/hosts files. otherwise the mysql authentication will fail and no data gets replicated.

Ok, I fixed that: the slave created on the master a database user with access permission on the wrong IP address. The cause is likely to be that on the slave I have more than one IP address on the same interface.

[till]

Should I remove everything and reinstall everything from scratch?

No, thats not nescessary as long as you do not add anything through the interface on the slave as this would cuase conflicts with the amster and replication will fail.

[gkovacs]

Has this bug been found and fixed since 3.0.1.4?

[till]

This is no behaviour that could be reproduced on any other server by one of the developers.

[ezhandossov]

I don't know about all other, but I don't have this problem any more. It just disappear... with no actions from me...

[gkovacs]

Originally Posted by till

This is no behaviour that could be reproduced on any other server by one of the developers.

Well, I just created a new ISPConfig installation based on 3.0.1.6, and the problem is still there. After a couple of clicks on PHP pages, lsof climbs to the tens of thousands.

If any of the developers are interested, I can give you SSH and HTTP access to this server. Message or email me and I'll send you the login details.

[SamTzu]

I have the same problem with .1.6.
On the server there is only myDNS, apache2 and mySQL installed.
No slave, only master.

[till]

The problem of the first poster was that he had manually changed mysql login details and forgot to change it in /etc/vlogger-dbi.conf too which caused the problems on his server. So it was not a bug in ISPConfig.

@SamTzu: Please make sure that the database login details in /etc/vlogger-dbi.conf are correct.