Mailing List Archive: mod

mod_cgi nph bug fix

Jul 12, 1995, 2:59 PM

Post #1 of 3 (284 views)

I discovered that my previous patch only fixed half the problem. I had a
script /cgi-bin/test which redirected to /cgi-bin/nph-test. What would
happen was the first script would get execed, and it would get the
internal redirect. It would then exec the nph script, which would
rapidly be killed (SIGTERM) by free_proc_chain, sending the user no
output. This fixes it. It does so by setting kill_how for the nph
children to kill_never. Is there any problem with this?

Patch is also available at http://www.netgen.com/~mkgray/apache/
along with the (new and less buggy) agent/referer log modules.

...Mkgray

*** ../shambhala6.0-orig/mod_cgi.c Sun Jul 9 14:44:26 1995
--- mod_cgi.c Wed Jul 12 17:57:07 1995
***************
*** 350,356 ****
add_common_vars (r);
cld.argv0 = argv0; cld.r = r; cld.nph = nph;

! if (!spawn_child (r->pool, cgi_child, (void *)&cld, kill_after_timeout,
&script_out, nph ? NULL : &script_in)) {
log_reason ("couldn't spawn child process", r->filename, r);
return SERVER_ERROR;
--- 350,357 ----
add_common_vars (r);
cld.argv0 = argv0; cld.r = r; cld.nph = nph;

! if (!spawn_child (r->pool, cgi_child, (void *)&cld,
! nph ? kill_never : kill_after_timeout,
&script_out, nph ? NULL : &script_in)) {
log_reason ("couldn't spawn child process", r->filename, r);
return SERVER_ERROR;
***************
*** 391,397 ****

/* Handle script return... */

! if (script_in) {
char *location;
int ret;

--- 392,398 ----

/* Handle script return... */

! if (script_in && !nph) {
char *location;
int ret;

Re: mod_cgi nph bug fix [ In reply to ]

rst at ai

Jul 12, 1995, 8:06 PM

Post #2 of 3 (278 views)

Permalink

Date: Wed, 12 Jul 1995 17:59:35 -0400 (EDT)
From: Matthew Gray <mkgray@netgen.com>
X-Sender: mkgray@bokonon
Organization: net.Genesis
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

I discovered that my previous patch only fixed half the problem. I had a
script /cgi-bin/test which redirected to /cgi-bin/nph-test. What would
happen was the first script would get execed, and it would get the
internal redirect. It would then exec the nph script, which would
rapidly be killed (SIGTERM) by free_proc_chain, sending the user no
output. This fixes it. It does so by setting kill_how for the nph
children to kill_never. Is there any problem with this?

Only one that I can see --- alloc.c never waits for kill_nevered
processes, so there is the chance that zombies might start piling up.
In my sandbox, this is (hopefully) fixed by adding a new kill
condition, just_wait, which is exactly like kill_never except that the
parent process *does* wait for the child.

Patch is also available at http://www.netgen.com/~mkgray/apache/
along with the (new and less buggy) agent/referer log modules.

Thanks. The pity is that these probably won't get the extensive
testing of some of the other stuff, because most of us hate the
feature, but I'll be happy to toss them into the next major spin.
Still, any chance you'll have time to toss in RefererIgnore?

(FWIW, my current plan is to take Saturday *off*, and spend Sunday
putting together a real Shambhala-based server distribution, with full
support directories, a few more optional modules --- these loggers,
Randy's imagemap module if it's in shape at that point, and Bambi's
config scripts if they look ready to go; if I get all that done, the
result will be called Apache 0.8. There may be another Shambhala spin
in the meantime, just to incorporate the bug fixes that I've got over
the past few days).

rst

Re: mod_cgi nph bug fix [ In reply to ]

mkgray at netgen

Jul 13, 1995, 6:42 AM

Post #3 of 3 (275 views)

Permalink

> Only one that I can see --- alloc.c never waits for kill_nevered
> processes, so there is the chance that zombies might start piling up.
> In my sandbox, this is (hopefully) fixed by adding a new kill
> condition, just_wait, which is exactly like kill_never except that the
> parent process *does* wait for the child.

Oops :-). I read the end of alloc.c as "if (p->kill_how == kill_never)
waitpid..." :-) A just_wait condition sounds good.

> Thanks. The pity is that these probably won't get the extensive
> testing of some of the other stuff, because most of us hate the
> feature, but I'll be happy to toss them into the next major spin.
> Still, any chance you'll have time to toss in RefererIgnore?

Fortunately loggers are relatively simple. I'll try to get
RefererIgnore into the referer_log module by Sunday so it can show up in
the release.

...Mkgray