Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

mod_fcgid

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


ricardo at smartcsc

Sep 21, 2009, 4:16 PM

Post #1 of 7 (530 views)
Permalink
mod_fcgid

I'm a long time user of mod_fcgi and would like to start using mod_fcgid. I've
been running mod_fcgi with a custom patch of mine. I like to see if it could
be included in mod_fcgid or maybe you can give me an other way to accomplish
what I need without the patch. What I have is one C program that lives on a
linux server. I want to use a web browser as the UI. The C program is a
classic "one instance to one UI". If 5 people want to run this program I need
five separate and persistent copies of the program running, one for each
person. When one is done then the program exits.
What I've done is sym-linked my program to make unique program names
like:
program-1
program-2
program-3
etc..
Then each browser asks for a different name.
plus the patch that allows setting killInterval to 0, so the process manager
won't kill my process ever. Here are the settings:
-maxClassProcesses 1 -singleThreshold 1 -killInterval 0.

I know I could have done it with FastCGIExternalServer, but I wanted
everything to be dynamic.

Here is the patch.

Index: fcgi_pm.c
===================================================================
--- fcgi_pm.c (revision 674)
+++ fcgi_pm.c (working copy)
@@ -1925,11 +1925,14 @@
if(fcgi_dynamic_epoch == 0) {
fcgi_dynamic_epoch = now;
}
+ if (dynamicKillInterval != 0)
+ {
if(((long)(now-fcgi_dynamic_epoch)>=dynamicKillInterval) ||
((fcgi_dynamic_total_proc_count+dynamicProcessSlack)>=dynamicMaxProcs))
{
dynamic_kill_idle_fs_procs();
fcgi_dynamic_epoch = now;
}
+ }
}

if(!callWaitPid) {
@@ -2060,11 +2063,14 @@
fcgi_dynamic_epoch = now;
}

+ if (dynamicKillInterval != 0)
+ {
if ((now-fcgi_dynamic_epoch >= (int) dynamicKillInterval) ||
((fcgi_dynamic_total_proc_count+dynamicProcessSlack) >=
dynamicMaxProcs)) {
dynamic_kill_idle_fs_procs();
fcgi_dynamic_epoch = now;
}
+ }
read_ready = 0;
}
else if (dwRet == WAKE_EVENT) {
Index: fcgi_config.c
===================================================================
--- fcgi_config.c (revision 674)
+++ fcgi_config.c (working copy)
@@ -1067,7 +1067,7 @@
return invalid_value(tp, name, NULL, option, err);
}
else if (strcasecmp(option, "-killInterval") == 0) {
- if ((err = get_u_int(tp, &arg, &dynamicKillInterval, 1)))
+ if ((err = get_u_int(tp, &arg, &dynamicKillInterval, 0)))
return invalid_value(tp, name, NULL, option, err);
}
else if (strcasecmp(option, "-updateInterval") == 0) {


--
Computer Services
Ricardo Cantu
Vice President

Home office
3506 Buchanan St Suite C
Wichita Falls, TX 76308
(940) 696-3010

El Paso branch
14553 Desierto Lindo Ave
El Paso, TX 79928
(915) 219-7119


trawick at gmail

Sep 22, 2009, 6:03 AM

Post #2 of 7 (509 views)
Permalink
Re: mod_fcgid [In reply to]

On Mon, Sep 21, 2009 at 7:16 PM, Ricardo Cantu <ricardo [at] smartcsc> wrote:

> I'm a long time user of mod_fcgi


BTW, I think you mean "mod_fastcgi." I haven't found a true "mod_fcgi,"
though some people on the web have used that to refer to mod_fcgid.


> and would like to start using mod_fcgid. I've
> been running mod_fcgi with a custom patch of mine. I like to see if it
> could
> be included in mod_fcgid or maybe you can give me an other way to
> accomplish
> what I need without the patch. What I have is one C program that lives on a
> linux server. I want to use a web browser as the UI. The C program is a
> classic "one instance to one UI". If 5 people want to run this program I
> need
> five separate and persistent copies of the program running, one for each
> person. When one is done then the program exits.
> What I've done is sym-linked my program to make unique program names
> like:
> program-1
> program-2
> program-3
> etc..
> Then each browser asks for a different name.
> plus the patch that allows setting killInterval to 0, so the process
> manager
> won't kill my process ever. Here are the settings:
> -maxClassProcesses 1 -singleThreshold 1 -killInterval 0.
>
> I know I could have done it with FastCGIExternalServer, but I wanted
> everything to be dynamic.
>

I think this may work for you:

DefaultMinClassProcessCount 1
DefaultMaxClassProcessCount 1
IdleTimeout 2147483647
ProcessLifetime 2147483647

Those magic values for IdleTimeout and ProcessLifetime are as close to
"unlimited" as you can get with the current code.

Note that these can only be set globally with mod_fcgid. That's probably a
much bigger problem than the "unlimited" hack.


ricardo at smartcsc

Sep 25, 2009, 7:08 AM

Post #3 of 7 (494 views)
Permalink
mod_fcgid [In reply to]

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.
Attachments: patch.diff (9.18 KB)


wrowe at rowe-clan

Sep 25, 2009, 9:01 AM

Post #4 of 7 (488 views)
Permalink
Re: mod_fcgid [In reply to]

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 :(


ricardo at smartcsc

Sep 25, 2009, 12:37 PM

Post #5 of 7 (487 views)
Permalink
Re: mod_fcgid [In reply to]

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 :(
>

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:

--
Computer Services
Ricardo Cantu
Vice President

Home office
3506 Buchanan St Suite C
Wichita Falls, TX 76308
(940) 696-3010

El Paso branch
1644 Ronnie Reif Dr.
El Paso, TX 79936
(915) 219-7119


ricardo at smartcsc

Sep 25, 2009, 12:44 PM

Post #6 of 7 (493 views)
Permalink
Re: mod_fcgid [In reply to]

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?


wrowe at rowe-clan

Sep 25, 2009, 1:08 PM

Post #7 of 7 (485 views)
Permalink
Re: mod_fcgid [In reply to]

Ricardo Cantu wrote:
>
> 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.

Ah ha - I misread your statement.

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.