Hi, I'm trying to use apache2-mpm-itk on a new ispconfig 3 installation. I mostly followed the instructions in The Perfect Server - Ubuntu 10.04 [ISPConfig 3] article, with some changes: I didn't install apache2-mpm-prefork, apache2-suexec and libapache2-mod-suphp, and instead installed apache2-mpm-itk. I then changed SuexecUserGroup to AssignUserId in ispconfig.vhost and apps.vhost. Furthermore, I copied all the prefork settings in apache2.conf to <IfModule mpm_itk_module>[...]</IfModule>. Now, the itk module seems to be working fine - i.e. the scripts run as the correct user. However, apache now produces an error when I try to restart it: Code: Address already in use: make_sock: could not bind to address 0.0.0.0:80 It seems that the init script is unable to terminate any of the apache processes running under the webX users. When I run 'service apache2 stop', all the root and www-data owned apache processes stop, but the webX owned ones remain. If I then kill them with 'killall -9 apache2', I can start apache again. This happens every time I had previously opened any site on the server, even ispconfig. If I don't open any site after starting apache, it restarts fine, since there is no webX owned apache process running. Did I mess something up in the configuration? What could be the cause of this problem?
Does no one have any advice on this? I would really appreciate it if someone could at least point me in the right direction. I can also provide config files and/or logs if it would help.
ISPConfig adds already config options for apache mpm-itk in the vhost, so it might be that your vhost changes are causing the problem. Please undo the cahnges and use the normal ispconfig vhost template file and then change a setting in every website so that the config files for every site gets rewritten. When you do this, make sure that mod_php is selected as php mode in every website and not cgi or fastcgi. Personally I would use apache-mpm-prefork with suexec and fastvgi instaed of apache-mpm-itk for production systems as this is has prooven to be a reliable and stable system configuration.
Thanks for replying, till. I only changed the ispconfig.vhost and apps.vhost files because they didn't seem to have mpm-itk support in them - there was a SuexecUserGroup directive and no AssignUserId directive. I never touched any of the "site" vhost files ([domain].vhost) as there is indeed mpm-itk configuration already in them. All the sites are configured to use mod_php as well. If I revert the changes in ispconfig.vhost or apps.vhost, apache fails to start, since suexec is not installed: Code: Invalid command 'SuexecUserGroup' Could this be the problem? Should I have installed apache2-suexec despite the fact I'm using mpm-itk instead?
Thats ok then, as long as you did not change the vhost templates. Then I have no idea what is causing your problem. As mentioned above, I dont use mpm-itk on my servers as suexec and php-fcgi works fine for me.
OK, thanks for trying to help anyway. Maybe someone else has had a similar problem? With suexec and php-fcgi, does php configuration (php_value, php_flag,...) work in .htaccess files? That's the main reason why I want to switch from suphp to mpm-itk.
No. For such php configuration directives ISPConfig has a php.ini settings field in the website settings.
I guess I'll take the suexec/php-fcgi option then, as I'm running out of time to get mpm-itk to work. Thanks, till.
possible fix Hi, I've just godt the exact same problem. I figured out that the webDAV part in vhost config template caused the problem. If I remove that it seems to work. So the problem is not related to ISPconfig other than the webDAV is part of std. vhost template. I guess this could be fixed somehow... - Mikael
Hi there, I've got a very similar problem, too. However, removing the DAV settings from the template didn't help at all. The difference is that, here, apachectl restart succeeds in restarting apache, whereas /etc/init.d/apache restart will leave the non-root processes hanging in limbo, effectively denying service throughout the server. This is on a Debian 6.0 server, but so far I haven't been able to reproduce the issue on another Debian 6.0 box, so it must be that there is a particular combination of factors involved here, and ISPConfig is just helping combine these factors in the "right" way. Cheers -- Romain
Hi again, While investigating this issue, I stumbled upon this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607072 I am happy to say that disabling mod_ruby immediately corrected the problem. As mentioned earlier, ISPConfig is not really to blame here. Hope this helps! Cheers -- Romain
