fcgid, class scope issue

[Jeff Trawick <tr...@gmail.com>]

Most process management controls, with the notable exception of the
global limit on processes, are configured on a class basis; a class is
defined essentially as a set of processes with the same startup
parameters within the same vhost.  (In this discussion, vhost is
httpd's native vhost concept, not that of some mass-vhost module.)

It is somewhat humorous that the code to enforce the vhost distinction
was added after the ancient mod_fcgid 2.2 release but before it became
an httpd sub-project, so our first release is where the issue became
noticeable.

Typical class equivalence checking is duplicated in the source code
with logic such as the following:

        if (current_node->inode == procnode->inode
            && current_node->deviceid == procnode->deviceid
            && !strcmp(current_node->cmdline, procnode->cmdline)
            && current_node->vhost_id == procnode->vhost_id
            && current_node->uid == procnode->uid
            && current_node->gid == procnode->gid)

(There are several different structures where these fields appear, and
no common substructure to collect them for easy comparison.)

Beyond the administrative considerations of controlling different
vhosts separately, at the implementation level the "within the same
vhost" restriction is a shortcut for considering that some additional
properties of the process -- notably the initial environment variable
settings -- also match.

This issue has been discussed before; from STATUS-FCGID:

    http://mail-archives.apache.org/mod_mbox/httpd-dev/201004.mbox/%3Cq2l81403a941004131831lce28460bqfc9fa53c2058e79b@mail.gmail.com%3E
    http://mail-archives.apache.org/mod_mbox/httpd-dev/201002.mbox/%3C4B7EA227.90100@binero.se%3E
    http://mail-archives.apache.org/mod_mbox/httpd-dev/200909.mbox/%3C4ABA234F.3000002@kippdata.de%3E
    http://mail-archives.apache.org/mod_mbox/httpd-dev/200909.mbox/%3C4239a4320909210011w6c716fe6kec5915edc49bc546@mail.gmail.com%3E
    https://issues.apache.org/bugzilla/show_bug.cgi?id=49902

The choices seem to be

1. global setting on scope: either the class spans all vhosts or it
remains vhost-specific

note that uid/gid/initial environment/etc. still must match; the vhost
restriction is simply removed, so it won't be truly global if any
settings for a particular script differ between vhost

2. allow a class name to be configured at vhost scope, so that some
subset of vhosts can share a class

this would be helpful if the process configuration is exactly the same
across vhosts but the admin wants to create a different set of process
pools

a less obvious way to configure this with choice 1 is to set the scope
to global and add one special environment variable setting that is
common among vhosts which should be managed together

IOW, as soon as you code

FcgidInitialEnv PROCCLASS foo1

in several vhosts (or several FcgidCmdOptions directives), that in
essence creates a class with custom scope.

--/--

So, am I missing something about the state of affairs here?  Is there
a different obvious solution besides #1 and 2 above?  Does anyone
strongly prefer option #2 given that setting scope to global and
configuring something unique for the desired custom scope (subset of
vhosts) would be sufficient?

I assume that some admins want to be able to manage by vhost, or we
would simply remove the vhost check and dispense with any class scope
configuration.  Is that a valid assumption?

--/--

Either way, a required implementation detail is changing comparison
logic like that long "if ()" quoted above to make a perfect check of
process equivalence, which requires inclusion of the startup envvars.
(We can't assign a request to a process which has different initial
envvar settings no matter what is configured for the scope.)  That in
turn needs a special structure to contain these process properties,
with optimized storage of envvars/cmdline and fast comparison for
equivalence, getting rid of these long, slightly different "if ()"
statements in a number of places.