suPHP/php-cgi, which I believe are necessary to allow the upload directories to function properly in Joomla, wordpress, and other CMS, is extremely resource heavy - as in 40-60% cpu _per instance_. So, I switched one of the biggest offenders to fast-CGI, so that he could test what would be necessary to use that with wordpress-MU. I ended up with not two, but eight jobs in the jobqueue, which stayed locked up. Subsequently, I enabled debugging, ran the server.sh process manually, and got this. (running it before debugging wouldn't actually complete) 16.08.2009-12:20 - DEBUG - Disable SSL for: <website1>.net 16.08.2009-12:20 - DEBUG - Writing the vhost file: /etc/httpd/conf/sites-available/cyantian.net.vhost 16.08.2009-12:20 - DEBUG - Processed datalog_id 133 16.08.2009-12:20 - DEBUG - Call function 'ssl' in plugin 'apache2_plugin' raised by event 'web_domain_update'. 16.08.2009-12:20 - DEBUG - Call function 'update' in plugin 'apache2_plugin' raised by event 'web_domain_update'. chmod: cannot access `/var/www/clients/client8/web3/*': No such file or directory 16.08.2009-12:20 - DEBUG - Disable SSL for: <website2>.net 16.08.2009-12:20 - DEBUG - Writing the vhost file: /etc/httpd/conf/sites-available/shivae.net.vhost 16.08.2009-12:20 - DEBUG - Processed datalog_id 134 16.08.2009-12:20 - DEBUG - Call function 'ssl' in plugin 'apache2_plugin' raised by event 'web_domain_update'. 16.08.2009-12:20 - DEBUG - Call function 'update' in plugin 'apache2_plugin' raised by event 'web_domain_update'. chmod: cannot access `/var/www/clients/client8/web3/*': No such file or directory 16.08.2009-12:20 - DEBUG - Disable SSL for: <website2>.net 16.08.2009-12:20 - DEBUG - Writing the vhost file: /etc/httpd/conf/sites-available/shivae.net.vhost 16.08.2009-12:20 - DEBUG - Processed datalog_id 135 16.08.2009-12:20 - DEBUG - Call function 'ssl' in plugin 'apache2_plugin' raised by event 'web_domain_update'. 16.08.2009-12:20 - DEBUG - Call function 'update' in plugin 'apache2_plugin' raised by event 'web_domain_update'. chmod: cannot access `/var/www/clients/client8/web3/*': No such file or directory Notice the 'cannot access' 'no such file or directory' message. The /var/www/clients/client8/web3 and web4 directories -DO- exist, but apparently the process doesn't have permissions to work on them, or something. Here's the ls -la for one of them ls -la /var/www/clients/client8/web4/ total 52 drwxr-xr-x 6 root root 4096 Aug 15 15:26 . drwxr-xr-x 4 root root 4096 Aug 15 15:26 .. drwxr-xr-x 2 web4 client8 4096 Aug 15 15:26 cgi-bin lrwxrwxrwx 1 web4 client8 37 Aug 15 15:26 log -> /var/log/ispconfig/httpd/<website1>.net drwxr-xr-x 2 web4 client8 4096 Aug 15 15:26 ssl drwxrwxrwx 2 web4 client8 4096 Aug 15 15:26 tmp drwxr-xr-x 24 web4 client8 4096 Aug 16 00:37 web Any suggestions?
The process is running as root user, os it definately has enough permissions. Except if you run the script manually for debugging? Which exact ISPConfig version do you use? Also post the output of: ls -la /var/www/clients/client8/web3
drwxr-xr-x 6 root root 4096 Aug 15 15:26 . drwxr-xr-x 4 root root 4096 Aug 15 15:26 .. drwxr-xr-x 2 web3 client8 4096 Aug 15 15:26 cgi-bin lrwxrwxrwx 1 web3 client8 35 Aug 15 15:26 log -> /var/log/ispconfig/httpd/<website>.net drwxr-xr-x 2 web3 client8 4096 Aug 15 15:26 ssl drwxrwxrwx 2 web3 client8 61440 Aug 17 00:04 tmp drwxrwxr-x 5 web3 client8 4096 Aug 17 00:13 web --- Running the latest beta version, was running the server.sh script as root for debugging purposes. Actually had to kill three other server.sh scripts that had locked up completely without giving reasons why, so I could run that one. Installed on CentOS 5.3 - ISPConfig-3.0.1.4-beta.tar.gz
Oh - any suggestions on reducing the cpu load when running suPHP? [edit] Never mind, I found out that you can't use eaccelerator if you're using suPHP. Too bad there's not an easy way to use the jailkit and flip all of the various sites to be owned by apache.
