On Wed, Sep 23, 2009 at 9:31 AM, Rainer Jung <rainer.j...@kippdata.de>wrote:
> When looking for an appropriate existing process to handle a request the > following data is used by mod_fcgid: > > - inode > inode num of the wrapper if one is used, > of the request filename otherwise > - deviceid > device id of the wrapper if one is used, > of the request filename otherwise > - share_grp_id > Always 0 if no wrapper is used, > -1 for one of the auth wrappers, > otherwise an incrementing id that is > unique across each wrapper with the same path > (but different vhosts or even only different extensions) > ids between different paths can overlap > - virtualhost: the pointer (!) to > r->server->server_hostname > I got educated on some of the ramifications of this while you were composing your e-mail ;) I just corrected some doc I wrote earlier. - uid: retrieved via ap_run_get_suexec_identity > - gid: retrieved via ap_run_get_suexec_identity > > If no process is found, a new one is created and carries the above data > coming from the request (and wrapper) which ran when it was created. > > Going a bit through the history of mod_fcgid, it seems that share_grp_id > was added to support a directive FCGIWrapperGroup (sic!). Later the > directive was removed, and the id was automatically incremented to > ensure separation. > > Again later there was a bug w.r.t. incomplete isolation of the default > env between vhosts, so virtualhost was added, but seems only necessary > for the non-wrapper case. > If two vhosts have the same server name, the default env can be shared, even if a wrapper is used. (I'll look at your e-mail in its entirely later. I'm awash in fcgid e-mails already, and the inbox directly connected to my bank account is overflowing :( )
