httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Cantu <>
Subject Re: mod_fcgid
Date Fri, 25 Sep 2009 19:44:36 GMT
On Friday 25 September 2009 1:37:52 pm Ricardo Cantu wrote:
> On Friday 25 September 2009 10:01:04 am William A. Rowe, Jr. wrote:
> > Ricardo Cantu wrote:
> > > Came across something else in testing mod_fcgid. mod_fastcgi would
> > > consider every symbolic link to the same program as a unique program
> > > and would start it up based on the program name and not the
> > > inode/device node. Since mod_fcgid only was checking inode/device node,
> > > symbolic links were considered the same as the real program. Does
> > > anybody think that is a needed behaviour? Why would you rename the
> > > program name and still want to consider it the same program? Either way
> > > I made a patch that can retain the old behaviour via a directive. If
> > > it's decided that the old behaviour is unneeded I can take the
> > > directive out and make it respect program name by default. I included
> > > the patch for review and if every thing is cool I'll write the xml for
> > > the new directive.
> >
> > Under unix, programs often change behavior based on argv[0], so the patch
> >  isn't really valid if the program filename isn't the same :(
Sorry for the double post!!!

That's the problem with mod_fcgid right now with out the patch.
argv[0] is different but mod_fcgid is not considering it different. It is
lumping together by inode only and not paying attention to basename
(argv[0]). Which can be different when using symbolic links.
The patch is so it can properly respect your statement.

> Under unix, programs often change behavior based on argv[0]
Here's the problem. If you have two different programs. Program1 and
Program2. They will have separate FCGIDDefaultMaxClassProcessCount which
is correct.
If you have one program: Program1 and then:
ln -s Program1 Program2

Program1 and Program2 get lumped into the same 
FCGIDDefaultMaxClassProcessCount which in my opinion is not correct.
The patch allows for both behaviors. 



View raw message