Bug 49902

in other words there is still a huge need for "class" to span over multiple virtualhosts.

(In reply to comment #0)
> FcgidMaxProcessesPerClass only counts inside virtualhost (or maybe virtualhosts
> with same ServerName? - which should be none). In original fastcgi
> implementation MaxProcessesPerClass could be used to limit max number of
> spawned process for same file (wrapper) thus making it possible to limit also
> "per virtual/system user". In fcgid such limit can't be established.

I fully support this statement.
When comparing to mod_fcgid-2.2 process management, ASF version spawns tons of unnecessary processes. Unnecessary at least when using the same FcgidWrapper+PHP for the same system user, just different VirtualHost.

Had to downgrade almost immediately after upgrade, due to server load jumping sky high...

Is there a way to achieve the old mod_fcgid proces management behaviour with proper config directives?
If not, I'm unhappily stuck with Ryan Pan version...

>Had to downgrade almost immediately after upgrade, due to server load jumping
sky high...

If you're referring to mod_fcgid 2.3.6, the issue is likely a regression in 2.3.6 which is fixed by the following:

Index: fcgid_spawn_ctl.c
===================================================================
--- fcgid_spawn_ctl.c	(revision 1037483)
+++ fcgid_spawn_ctl.c	(working copy)
@@ -178,7 +178,7 @@
         if (current_node->inode == command->inode
             && current_node->deviceid == command->deviceid
             && !strcmp(current_node->cmdline, command->cmdline)
-            && current_node->vhost_id == sconf->vhost_id
+            && current_node->vhost_id == command->vhost_id
             && current_node->uid == command->uid
             && current_node->gid == command->gid)
             break;

(In reply to comment #3)
> >Had to downgrade almost immediately after upgrade, due to server load jumping
> sky high...
> 
> If you're referring to mod_fcgid 2.3.6, the issue is likely a regression in
> 2.3.6 which is fixed by the following:

You got me wrong.
Server load was not affected by wrong accounting on processess.
It is affected by NUMBER of started processess, eating up available RAM, causing excessive swapping...

In mod_fcgid-2.2 processess started by fcgiwrapper were of the same class if they were run with same wrapper by the same owner.

In mod_fcgid-2.3 these processess have different class also if they are run in  different virtual hosts.

with mod_fcgid-2.2 and fcgi wrapper for php, we could serve dozens of virtual hosts (i.e. subdomains) for single customer with single php process. mod_fcgid-2.3 needs dozens of PHP processess to do the same job.
That's simple waste as whole virtual host environment goes with http request in fcgi protocol.

I think there shoud be at least alternative for default process management in mod_fcgid-2.3. Maybe optional explicit class name in FcgidWrapper and/or FcgidCmdOptions directive?

It looks like this is still happening on a Debian Squeeze system with mod fcgid 2.3.6. Has there been any progress regarding this issue?! I rather not compile the mod myself and go back to 2.2, but if that's the only solution right now i probably have to.

Small update: Applying Jeff Trawick's patch (see above) to the Debian mod_fcgid 2.3.6 sources fixed it for me. With this patch FcgidMaxProcessesPerClass now works per vhost again, no matter which user, servername or wrapper is used within that vhost. Probably best to fix this before the mass switches over to 2.3.6 (/7) or a lot of servers will go OOM. Thanks Jeff, u saved the day!

Hello !

Any news with this bug ?

Acorrding to the docs of FcgidMaxProcessesPerClass Directive:

This directive sets the maximum number of processes that can be started for each process class.

This setting will apply to all applications spawned for this server or virtual host. Use FcgidCmdOptions to apply this setting to a single application.

So shouldn't this solve your problem?
FcgidCmdOptions /usr/local/bin/wrapper MaxRequestsPerProcess 10

Ehm, I meant of course MaxProcesses:
FcgidCmdOptions /usr/local/bin/wrapper MaxProcesses 10

I have been building out a tweaked LAMP set up on a fresh Debian Squeeze server.

Server version: Apache/2.2.16 (Debian)
Architecture:   64-bit
Server MPM:     Worker

Utilising fcgid_module (shared), 2.3.6-1 (Squeeze stable as of writing).

My story is similar to @Joost I guess.

I've had zero luck trying to make FcgidMaxProcessesPerClass work, either at the Server or Virtual level. I put in some serious effort to get it to work but to no avail. So I think that is another confirmed case of this bug in action.

I apt-get source libapache2-mod-fcgid, applied Jeff's patch listed here (by hand), installed etc and *shit started to work*. Kudos @Jeff for sharing this :)

I was then able to set a default server FcgidMaxProcessesPerClass and then override for specific vhosts too. I am still in the testing phase with my latest cfg's but its looking very promising indeed.

----

@Miroslav, when I had zero luck with FcgidMaxProcessesPerClass, I moved on to try FcgidCmdOptions but no matter what I tried, I couldn't get any of the potential options to take effect :(
Specifically, I tried passing env vars to the wrapper, they were not being set (or I was doing it wrong).
I also tried specifying MaxProcesses but that didn't work either.

The docs are not that clear on what to specify as the *command*, apache docs suggest the wrapper but that seems to have no effect. I also tried specificing php5-cgi as the command, also no effect.

I have _NOT_ re-tested FcgidCmdOptions since patching but I doubt that is fixed or perhaps I'm just *doing it wrong*.

Revision 1037727 - Directory Listing
Modified Mon Nov 22 14:08:29 2010 UTC (13 months, 3 weeks ago) by trawick

Fix regression in 2.3.6 which broke process controls when using vhost-
specific configuration.

vhost_id was referenced from the wrong structure, and never matched
unless there were no vhost-specific directives in the vhost of the
request.


Fixed for 2.3.7.  Closing

Due to the risk of DoS, i've requested a CVE for this bug:

  http://www.openwall.com/lists/oss-security/2012/03/15/10

Having a released upstream version that respects the administrator's configuration for FcgidMaxProcessesPerClass would be great :)

This is now known as CVE-2012-1181

*** Bug 52695 has been marked as a duplicate of this bug. ***