Strange Problem With Apche and FastCGI

[Andrew_Pa]

Hello to the team!

Very often I have the following problem. Several sites are down and I get error 500. In the domain log file I see this

mod_fcgid: can't apply process slot for /var/www/cgi-bin/cgi_wrapper/cgi_wrapper

In the apache log, there is nothing for this problem.

If I restart apache everything works fine, but after a few hours or next day, the problem appear again.

My /etc/httpd/conf.d/fcgid.conf file has the following settings

LoadModule fcgid_module modules/mod_fcgid.so

<IfModule mod_fcgid.c>

<IfModule !mod_fastcgi.c>
AddHandler fcgid-script fcg fcgi fpl
</IfModule>

FcgidIPCDir /var/run/mod_fcgid/sock
FcgidProcessTableFile /var/run/mod_fcgid/fcgid_shm


FcgidIdleTimeout 3600
#FcgidProcessLifeTime 30
FcgidProcessLifeTime 10000
#FcgidMaxProcesses 20
FcgidMaxProcesses 64
#FcgidMaxProcessesPerClass 8
FcgidMaxProcessesPerClass 25
FcgidMinProcessesPerClass 0
#FcgidConnectTimeout 30
FcgidConnectTimeout 60
FcgidIOTimeout 45
FcgidInitialEnv RAILS_ENV production
FcgidIdleScanInterval 10
FcgidMaxRequestLen 1073741824

IPCCommTimeout 360
IPCConnectTimeout 360
</IfModule>

I try to raise FcgidMaxProcesses to 64, but the problem appears again.


Can help to to stop this problem?

Thank you!

PS: The sites I get error 500, has the setting of FastCgi at PHP settings.

 

[IgorG]

Have you tried

chmod 755 /var/log/httpd

?

 

[Andrew_Pa]

Thank you for your quick answer!

No I haven't 755 to this folder.

I already changed and now I will observe it to see if wrong happens again!

Technically, why this problem appears? mod_fcgid tried to write to the httpd folder and it couldn't?

Thank you very much again!

 

[keny]

Same problem here with plesk 11.5 but /var/log/httpd do not exist !

Solution ?

 

[abdi]

Try the following options:

vim /etc/httpd/conf.d/fcgid.conf

and increase from the default (6 processes) to

FcgidMaxProcesses 600

 

[kiav]

The same problem.

# ps -C php-cgi | wc -l
4

But fcgid.conf:

LoadModule fcgid_module modules/mod_fcgid.so

<IfModule mod_fcgid.c>

<IfModule !mod_fastcgi.c>
AddHandler fcgid-script fcg fcgi fpl
</IfModule>

FcgidIPCDir /var/run/mod_fcgid/sock
FcgidProcessTableFile /var/run/mod_fcgid/fcgid_shm

FcgidIdleTimeout 40
FcgidProcessLifeTime 30
FcgidMaxProcesses 120
FcgidMaxProcessesPerClass 120
FcgidMinProcessesPerClass 0
FcgidConnectTimeout 30
FcgidIOTimeout 45
FcgidInitialEnv RAILS_ENV production
FcgidIdleScanInterval 10

</IfModule>

What is the reason?

 

[HostaHost]

This error can also occur if the register_globals directive is still present in the php.ini and you're trying to use php 5.6. In Plesk versions where you can select to use the Plesk-provided php 5.6, if you have register_globals set to "yes" or "no", your php apps will crash with that same "mod_fcgid: can't apply process slot for /var/www/cgi-bin/cgi_wrapper/cgi_wrapper" error logged. If you set register_globals to "default", plesk will remove it from the php.ini and then things will work.

 

[UFHH01]

Since "PHP 5.4.0", the setting "register_globals" has been removed from the php.ini . If you still setup this very old definition, then this would have be done on purpose and for a specific reason. Plesk itself doesn't setup this definition using standard configuration(s).

 

[HostaHost]

Since "PHP 5.4.0", the setting "register_globals" has been removed from the php.ini . If you still setup this very old definition, then this would have be done on purpose and for a specific reason. Plesk itself doesn't setup this definition using standard configuration(s).

Why do you regularly jump into threads and give incorrect information?

Plesk has a PHP Settings area going all the way back to version 10, which, as anyone would know, means back to php versions as old as 5.1 (centos 5) or 5.3 (centos 6). If, at any point in time, you or your customers chose to set the register_globals setting to OFF, for security reasons, then Plesk explicitly adds register_globals=off (or register_globals=on if you chose the other option) to the resulting php.ini that PLESK CONTROLS. If, at any later date, you choose to go into Plesk, then hosting settings, and change the php version to 5.4, 5.5 or 5.6, that same register_globals setting that Plesk added for you remains there. Plesk DOES NOT have the logic built in to say oh, this person is changing the version to 5.4 or later, I should now remove the register_globals= setting I added to php.ini previously, it will just leave it there, in the file that it controls. You must set it back to "default" for the value to be removed from php.ini. If you had set this, even as far as years ago, and now upgrade to 5.4+, your site will be down until you realize the issue is register_globals and TELL PLESK to remove it.

 

[UFHH01]

Hi Hostasaurus.Com,

I'm sorry that you misinterpreted my words. If you have any questions to my above post, you are welcome to start a private conversation with me.

 

[HostaHost]

No question at all. You stated Plesk itself would never put register_globals definition in the php.ini, and you were shown to be wrong.

 

[UFHH01]

Hi Hostasaurus.Com,

well, sorry to point that out, but I wrote:

"If you still setup this very old definition, then this would have be done on purpose and for a specific reason" and "Plesk itself doesn't setup this definition using standard configuration(s)." In detail, this means, that the STANDARD SETTING is "register_globals = 0" - only users who change this setting to "on" will have a definition "register_globals = 1" in their php.ini ... and if you change the PHP - version, the very same previous setting will be set in your new PHP - version as well, because this is stored in your psa - database for that (sub)domain.
So if you don't change the "register_globals" - setting, then you will never experience issues for apache and fastcgi.

Sorry if you misunderstood my post.

 

[HostaHost]

No. If you started out on Plesk 10 and left register_globals set to "default", this caused it to be explicitly set to off in the php.ini file. If you upgraded to Plesk 11 and 12, they took default (which was off) and kept the setting as off, causing the value to be set with no action on the user's part.

only users who change this setting to "on" will have a definition "register_globals = 1" in their php.ini

Additionally, those who intentionally set it to off for security reasons, in Plesk 11+, will have that "register_globals = Off" value remain there even in php versions it is not compatible with. It has nothing to do with setting it to On.