Apache will not load

Probably did the person who previously managed server. Is way to restore restore / generate new, clean templates?
 
I installed everything again (clean install). php-fpm work's but i have problem with some htaccess files - for example dosen't work cakePHP rewrite for webroot:
Code: 
<IfModule mod_rewrite.c>
   RewriteEngine on
   RewriteRule    ^$ app/webroot/    [L]
   RewriteRule    (.*) app/webroot/$1 [L]
</IfModule>
Roundcube and phpMyadmin does not work:
File not found.

Code: 
[proxy_fcgi:error] [pid 32125:tid 47739653056256] [client 89.69.222.214:40024] AH01071: Got error 'Primary script unknown\n'

How to solve this problem?
 
Last edited:
I don't know why but this dosen't work on our server. We have VPS OpenVZ (maybe this is the reason).
When i refresh site many times in top appear more processes than in limits.conf.

regards
 
I'm running Directadmin in OpenVZ container as well, and have never faced an issue with overcoming the limit.
Note, the limit does not affect number of apache processes (at least in my experience). It actually should limit number of PHP-CGI processes.
 
Here is the top screen:
X7wUHck.jpg

/etc/security/limits.conf
Code: 
*
wybrzeze hard nproc 5
*

Do you have any idea why the limits do not work? Maybe the configuration is incorrect?
No limits can overload the server (often simply refresh the page) :(.

Regards
 
Last edited:
Exist patch compatible with DA?
After manual patch i can't build suphp.

Code: 
root@server:/usr/local/directadmin/custombuild# ./build suphp
File already exists:    suphp-0.7.1.tar.gz
MD5 Checksum on suphp-0.7.1.tar.gz passed.
File already exists:    patches/suphp_calling_user.patch
MD5 Checksum on patches/suphp_calling_user.patch passed.
File already exists:    patches/suphp_script_name.patch
MD5 Checksum on patches/suphp_script_name.patch passed.
File already exists:    patches/suphp_attachment.patch
MD5 Checksum on patches/suphp_attachment.patch passed.
Found /usr/local/directadmin/custombuild/suphp-0.7.1.tar.gz
Extracting ...
Done.
./build: line 3992: cd: suphp-0.7.1: No such file or directory
./build: line 3998: ../patches/suphp_calling_user.patch: No such file or directory
./build: line 3999: ../patches/suphp_script_name.patch: No such file or directory
./build: line 4001: ../patches/suphp_attachment.patch: No such file or directory
Can't do inplace edit: ./configure is not a regular file.
Configuring suphp-0.7.1...
/usr/local/directadmin/custombuild/configure/suphp/configure.suphp: line 3: ./configure: is a directory

*** There was an error while trying to configure suPHP. Check the configure/suphp/configure.suphp file
 
Though I've met the patch, I haven't tried it myself yet. I should had inform you about that.
I've checked, and I see the patch is created for suphp-0.6.1.

How did you apply the patch?
 
zEitEr said:
Though I've met the patch, I haven't tried it myself yet. I should had inform you about that.
I've checked, and I see the patch is created for suphp-0.6.1.

How did you apply the patch?
Click to expand...
Code: 
root@server:/usr/local/directadmin/custombuild# cd suphp-0.7.1/
root@server:/usr/local/directadmin/custombuild/suphp-0.7.1# wget http://mkwm.zielonki.info/suphp_patch.diff -O-|patch -p1
patching file src/API.hpp
patching file src/API_Linux.cpp
patching file src/API_Linux.hpp
patching file src/Application.cpp
Hunk #1 succeeded at 379 (offset -5 lines).
patching file src/Configuration.cpp
patching file src/Configuration.hpp
patching file src/Makefile.in

Then i did tar archive and replaced md5 checksum in version.txt
I can manually install patched suphp but probably it's not good solution with DA?
 
Well, this patch if for the latest suphp -0.7.1, and I've installed it with custombuild 1.2.37 without any issue.

Then created a file /etc/pam.d/suphp with the following content:

Code: 
auth sufficient pam_permit.so
session required pam_limits.so conf=/usr/local/suphp/etc/security/limits.conf
session required pam_permit.so

and a file /usr/local/suphp/etc/security/limits.conf with the following content:
Code: 
* soft nproc 2
* hard nproc 2

And now I'm testing.
 
I was able to build suPHP with patch. Unfortunately, the limits dosen't work.
Is it possible that I miss something in the system?
I created the files (/etc/pam.d/suphp and /usr/local/suphp/etc/security/limits.conf) and added pam_service=suphp in suphp configuration file (global section).
 
zEitEr said:
Well, maybe I am doing anything wrong... but the patch does not seem to be working for me. I need to check it out.

But this (not related to the patch) seems to be working

Code: 
<FilesMatch "\.(inc|php|php3|php4|php5|php6|phtml|phps)$">
RLimitNPROC 5
</FilesMatch>
Click to expand...

I'm tested. For me it dosen't work: (.
I'm not sure, but maybe at a time when very fast refresh the page (F5 button does not let go) apache start a new process. The new process apache * RLimitNPROC [VALUE] = number of new processes.

There is no limit to the user (like with limits.conf) only limit processes for each apache instance.
I'm not sure what I wrote. Maybe I understood it wrong?

There is no easy way to limit the number of CGI processes without using fastcgi?

Regards
 
Last edited:
I've added for testing purposes that code into a VirtualHost section

Code: 
<FilesMatch "\.(inc|php|php3|php4|php5|php6|phtml|phps)$">
RLimitNPROC 5
</FilesMatch>

So I guess it would limit only the number of processes within one virtual host. Still more testing is needed.
And I've created a PHP script which runs long so I could test it:

PHP: 
<?php
for ($i=0; $i<100; $i)
{
    print "$i<br>\n";
    sleep(100);
}
?>

And requested the script in several tabs of my browser. Those over the limit gave me 500 error.
 
From official docs:

This applies to processes forked off from Apache children servicing requests, not the Apache children themselves. This includes CGI scripts and SSI exec commands, but not any processes forked off from the Apache parent such as piped logs.

Process limits control the number of processes per user.

Note
If CGI processes are not running under user ids other than the web server user id, this directive will limit the number of processes that the server itself can create. Evidence of this situation will be indicated by cannot fork messages in the error_log.
Click to expand...

http://httpd.apache.org/docs/2.2/mod/core.html#rlimitnproc
 
You must log in or register to reply here.
Back
Top