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. Comments?
