You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@remulak.net> on 2001/10/23 08:31:52 UTC

results with 2.0.27-dev on daedalus

We were on 2.0.27-dev for an hour and a half tonight. 

We very quickly hit MaxClients, which is at 600, because we were getting
pounded with requests for xml.apache.org from one client.  Once I put
him in the penalty box, we were able to handle the workload without a
problem.

But we took two seg faults, so I moved us back to 2.0.24. The URL was
http://search.apache.org/ .  This was a POST request.  The dumps are
/usr/local/apache2.0.26-debug/corefiles/httpd.core.1 and .2, and they
look the same.

#0  0x80739be in core_input_filter (f=0x8125364, b=0x81dd7fc,
    mode=AP_MODE_BLOCKING, readbytes=0xbfbf7660) at core.c:2875
#1  0x806cebd in ap_get_brigade (next=0x8125364, bb=0x81dd7fc,
    mode=AP_MODE_BLOCKING, readbytes=0xbfbf7660) at util_filter.c:250
#2  0x805e4c7 in ap_get_client_block (r=0x81dd484,
    buffer=0xbfbf96e8
"keyword=Windows+XP&results=20&what=httpd.apache.org&version=2",
bufsiz=8192) at http_protocol.c:1377
#3  0x281b57b8 in cgi_handler (r=0x81dd484) at mod_cgi.c:629
#4  0x8062ff7 in ap_run_handler (r=0x81dd484) at config.c:185
#5  0x806358f in ap_invoke_handler (r=0x81dd484) at config.c:344
#6  0x8060ac5 in ap_internal_redirect (new_uri=0x81dd45c "/index.cgi",
    r=0x81da03c) at http_request.c:444
#7  0x281ecca5 in handle_dir (r=0x81da03c) at mod_dir.c:194
#8  0x8062ff7 in ap_run_handler (r=0x81da03c) at config.c:185
#9  0x806358f in ap_invoke_handler (r=0x81da03c) at config.c:344
#10 0x8060675 in ap_process_request (r=0x81da03c) at http_request.c:286
#11 0x805c402 in ap_process_http_connection (c=0x8125114) at
http_core.c:289
#12 0x806b56f in ap_run_process_connection (c=0x8125114) at
connection.c:82
#13 0x806b72d in ap_process_connection (c=0x8125114) at connection.c:219
#14 0x8061bf0 in child_main (child_num_arg=318) at prefork.c:830
#15 0x8061d46 in make_child (s=0x8095974, slot=318) at prefork.c:917
#16 0x8061f99 in perform_idle_server_maintenance (p=0x809500c)
    at prefork.c:1058
#17 0x806235a in ap_mpm_run (_pconf=0x809500c, plog=0x80ce00c,
s=0x8095974)

Re: results with 2.0.27-dev on daedalus :-)

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Daniel Stone" <da...@sfarc.net>
Sent: Wednesday, October 24, 2001 3:20 AM


> On Tue, Oct 23, 2001 at 10:51:52PM -0400, Greg Ames wrote:
> > I'm happy to report that I switched us over to 2.0.27-dev on Tuesday,
> > 23-Oct-2001 18:24:58 PDT, and we're doing fine after an hour and a
> > half.  Please speak up if you notice anything bad.  This has got Cliff's
> > fix for last night's seg fault, and Ryan's fix for child exit status.
> > 
> > To be more precise, it's HEAD from this evening, plus Jeff's patch to
> > stash away input buffers for debugging, and a patch to bump up
> > HARD_SERVER_LIMIT to 1000.  I think it would be reasonable to commit
> > either of those.  Opinions?
> 
> Where are said patches?

Better yet... commit them already ;)


Re: results with 2.0.27-dev on daedalus :-)

Posted by Greg Ames <gr...@remulak.net>.
Joshua Slive wrote:

> 2. SSI is not getting activated properly.  httpd.conf says:
> <Files ~ "\.html$">
>     SetOutputFilter INCLUDES
> </Files>
> 
> But it should say:
> <FilesMatch "\.html(\..+)?$">
>     SetOutputFilter INCLUDES
> </FilesMatch>
> (from httpd-std.conf)

OK, the one above worked.  I gracefully restarted the server, so it's in
effect now.

> or, more simply,
> AddOutputFilter INCLUDES .html

this one didn't work

Greg

Re: results with 2.0.27-dev on daedalus :-)

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
> 
> Apropos of nothing.  Given a request with no language, yes,
> it will serve.  But in the grand scheme, .html.html aught be
> treated as whatever one sets their DefaultLanguage to, which
> would undermine the original workaround.

And if there is NO DefaultLanguage?

> In any case, given multiple requests of equivilant 'quality' -
> we should suggest MULTIPLE CHOICES by default, override by
> LanguagePriority if the admin desires.

I doubt anyone disagrees with this, but you seem to be
missing boundary conditions and only focussing on the
main probabilities.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: results with 2.0.27-dev on daedalus :-)

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Friday, October 26, 2001 11:31 AM


> "William A. Rowe, Jr." wrote:
> > 
> > > > User accepts no specified, we serve none [Also wrong,
> > > > also MULTIPLE_CHOICES should be the default behavior!!!]
> > >
> > > Unclear.  What about a request for foo.html, with no
> > > Accept-Language field but with 'Accept: text.html',
> > > and files foo.html.en, foo.html.fr, and foo.html.html?
> > > Are you suggesting we should send a 300 for that instead
> > > of foo.html.html?
> > 
> > Forget foo.html.html, we hope to do away with that this
> > time around.
> 
> No, don't forget about it -- answer my question.  It is germane.

Apropos of nothing.  Given a request with no language, yes, it will
serve.  But in the grand scheme, .html.html aught be treated as whatever
one sets their DefaultLanguage to, which would undermine the original
workaround.

In any case, given multiple requests of equivilant 'quality' - we should
suggest MULTIPLE CHOICES by default, override by LanguagePriority if the
admin desires.

Any which way, I'll try to wrap a patch this weekend, hopefully tommorow
morning.  It's been a rough week...

Bill


Re: results with 2.0.27-dev on daedalus :-)

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
> 
> > > User accepts no specified, we serve none [Also wrong,
> > > also MULTIPLE_CHOICES should be the default behavior!!!]
> >
> > Unclear.  What about a request for foo.html, with no
> > Accept-Language field but with 'Accept: text.html',
> > and files foo.html.en, foo.html.fr, and foo.html.html?
> > Are you suggesting we should send a 300 for that instead
> > of foo.html.html?
> 
> Forget foo.html.html, we hope to do away with that this
> time around.

No, don't forget about it -- answer my question.  It is germane.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: results with 2.0.27-dev on daedalus :-)

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Thursday, October 25, 2001 9:56 AM


> "William A. Rowe, Jr." wrote:
> > 
> > To be RFC compliant we must start by fixing today's wrong behavior.
> > 
> > User accepts .en and .fr at q=.5, server chooses one
> > [WRONG: MULTIPLE_CHOICES should be presented!!!]
> 
> Both of those are at q=0.5, or only .fr?

At eqivilant quality.  Were they different, the higher value would win.

> > User accepts no specified, we serve none [Also wrong,
> > also MULTIPLE_CHOICES should be the default behavior!!!]
> 
> Unclear.  What about a request for foo.html, with no
> Accept-Language field but with 'Accept: text.html',
> and files foo.html.en, foo.html.fr, and foo.html.html?
> Are you suggesting we should send a 300 for that instead
> of foo.html.html?

Forget foo.html.html, we hope to do away with that this time around.

Presuming no other factors, two languages available, and _no_ stated
accept, we should present MULTIPLE_CHOICES as in the case above.

All this is overridden at the administrator's discression.  I'm just
pointing out where we went wrong; it confused the issue when coding this
patch to start from the wrong point.

Bill


Re: results with 2.0.27-dev on daedalus :-)

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
> 
> To be RFC compliant we must start by fixing today's wrong behavior.
> 
> User accepts .en and .fr at q=.5, server chooses one
> [WRONG: MULTIPLE_CHOICES should be presented!!!]

Both of those are at q=0.5, or only .fr?

> User accepts no specified, we serve none [Also wrong,
> also MULTIPLE_CHOICES should be the default behavior!!!]

Unclear.  What about a request for foo.html, with no
Accept-Language field but with 'Accept: text.html',
and files foo.html.en, foo.html.fr, and foo.html.html?
Are you suggesting we should send a 300 for that instead
of foo.html.html?
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: results with 2.0.27-dev on daedalus :-)

Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:

> > 2. SSI is not getting activated properly.  httpd.conf says:
> > <Files ~ "\.html$">
> >     SetOutputFilter INCLUDES
> > </Files>
> >
> > But it should say:
> > <FilesMatch "\.html(\..+)?$">
> >     SetOutputFilter INCLUDES
> > </FilesMatch>
> > (from httpd-std.conf)
> > or, more simply,
> > AddOutputFilter INCLUDES .html
> >
> > The problem with the present configuration is that it does not catch
> > .html.en (etc).  So, as Marc pointed out, some docs are not getting parsed.
> 
> Ah ha... but that should only apply to certain areas, and follows different
> rules appropriately.
> 
> In the /error/ alias, we do;
> 
>         AddOutputFilter Includes html

as I mentioned in another post, 

AddOutputFilter INCLUDES .html

didn't work as a general fix.  I don't know why.  The fancier regex did
work.

> Are your sure your httpd.conf isn't out of date wrt httpd-std.conf?

I'm sure daedalus's config isn't automatically kept up to date with
httpd-std.conf.  If I notice stuff that must be changed, I do it.  Other
eyeballs on the config file would be appreciated.   

Greg

Re: results with 2.0.27-dev on daedalus :-)

Posted by jo...@slive.ca.
On Wed, 24 Oct 2001, William A. Rowe, Jr. wrote:

> From: "Joshua Slive" <jo...@slive.ca>
> >
> > The problem with the present configuration is that it does not catch
> > .html.en (etc).  So, as Marc pointed out, some docs are not getting parsed.
>
> Ah ha... but that should only apply to certain areas, and follows different
> rules appropriately.
>
> In the /error/ alias, we do;
>
>         AddOutputFilter Includes html
>
> So there should be no problem there.  Which directory are you speaking of?
>

Just the manual directories on httpd.apache.org.

> Are your sure your httpd.conf isn't out of date wrt httpd-std.conf?

The httpd.conf on daedalus was indeed out of date.  It is fixed now to use
the proper FilesMatch.  Greg reported that, for some reason, the
AddOutputFilter configuration didn't work.  I haven't tested it myself.
[I know what you mean about swamped.]

Joshua.


Re: results with 2.0.27-dev on daedalus :-)

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Joshua Slive" <jo...@slive.ca>
Sent: Wednesday, October 24, 2001 10:47 AM


> There are a couple configuration issues with httpd.apache.org/docs* at the
> moment:
> 
> 1. We are back in "no acceptable variant" hell.  I think OtherBill is still
> working on the directive to fix this, but I'm not sure.

Yes, it's a deeper issue than I expected.

To be RFC compliant we must start by fixing today's wrong behavior.

User accepts .en and .fr at q=.5, server chooses one [WRONG: MULTIPLE_CHOICES
should be presented!!!]

User accepts no specified, we serve none [Also wrong, also MULTIPLE_CHOICES
should be the default behavior!!!]

So, the ForceLanguagePreference has to toggle two behaviors independantly;

a. Allow the user to override MULTIPLE_CHOICES

b. Allow the user to override NONE_ACCEPTABLE

I've been SWAMPED [well, in Chicago here, that's literally true, but I really
mean the work thing ;]

> 2. SSI is not getting activated properly.  httpd.conf says:
> <Files ~ "\.html$">
>     SetOutputFilter INCLUDES
> </Files>
> 
> But it should say:
> <FilesMatch "\.html(\..+)?$">
>     SetOutputFilter INCLUDES
> </FilesMatch>
> (from httpd-std.conf)
> or, more simply,
> AddOutputFilter INCLUDES .html
> 
> The problem with the present configuration is that it does not catch
> .html.en (etc).  So, as Marc pointed out, some docs are not getting parsed.

Ah ha... but that should only apply to certain areas, and follows different
rules appropriately.

In the /error/ alias, we do;

        AddOutputFilter Includes html

So there should be no problem there.  Which directory are you speaking of?

Are your sure your httpd.conf isn't out of date wrt httpd-std.conf?

Bill


RE: results with 2.0.27-dev on daedalus :-)

Posted by Joshua Slive <jo...@slive.ca>.
> On Tue, Oct 23, 2001 at 10:51:52PM -0400, Greg Ames wrote:
> > I'm happy to report that I switched us over to 2.0.27-dev on Tuesday,
> > 23-Oct-2001 18:24:58 PDT, and we're doing fine after an hour and a
> > half.  Please speak up if you notice anything bad.  This has got Cliff's
> > fix for last night's seg fault, and Ryan's fix for child exit status.
> >
> > To be more precise, it's HEAD from this evening, plus Jeff's patch to
> > stash away input buffers for debugging, and a patch to bump up
> > HARD_SERVER_LIMIT to 1000.  I think it would be reasonable to commit
> > either of those.  Opinions?

There are a couple configuration issues with httpd.apache.org/docs* at the
moment:

1. We are back in "no acceptable variant" hell.  I think OtherBill is still
working
on the directive to fix this, but I'm not sure.

2. SSI is not getting activated properly.  httpd.conf says:
<Files ~ "\.html$">
    SetOutputFilter INCLUDES
</Files>

But it should say:
<FilesMatch "\.html(\..+)?$">
    SetOutputFilter INCLUDES
</FilesMatch>
(from httpd-std.conf)
or, more simply,
AddOutputFilter INCLUDES .html

The problem with the present configuration is that it does not catch
.html.en (etc).  So, as Marc pointed out, some docs are not getting parsed.

Joshua.


Re: results with 2.0.27-dev on daedalus :-)

Posted by Daniel Stone <da...@sfarc.net>.
On Tue, Oct 23, 2001 at 10:51:52PM -0400, Greg Ames wrote:
> I'm happy to report that I switched us over to 2.0.27-dev on Tuesday,
> 23-Oct-2001 18:24:58 PDT, and we're doing fine after an hour and a
> half.  Please speak up if you notice anything bad.  This has got Cliff's
> fix for last night's seg fault, and Ryan's fix for child exit status.
> 
> To be more precise, it's HEAD from this evening, plus Jeff's patch to
> stash away input buffers for debugging, and a patch to bump up
> HARD_SERVER_LIMIT to 1000.  I think it would be reasonable to commit
> either of those.  Opinions?

Where are said patches?

:) d

-- 
Daniel Stone						    <da...@sfarc.net>
* Robot101 ponders writing a debian devel FAQ
<Joy> Q: *
<Joy> A: first of all, do you have a sister?
<Kamion> Q: I have a bug report
<Kamion> A: reassign xxxxx dpkg

Re: results with 2.0.27-dev on daedalus :-)

Posted by Greg Ames <gr...@remulak.net>.
I'm happy to report that I switched us over to 2.0.27-dev on Tuesday,
23-Oct-2001 18:24:58 PDT, and we're doing fine after an hour and a
half.  Please speak up if you notice anything bad.  This has got Cliff's
fix for last night's seg fault, and Ryan's fix for child exit status.

To be more precise, it's HEAD from this evening, plus Jeff's patch to
stash away input buffers for debugging, and a patch to bump up
HARD_SERVER_LIMIT to 1000.  I think it would be reasonable to commit
either of those.  Opinions?

Greg

Re: results with 2.0.27-dev on daedalus

Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 23 Oct 2001, Greg Ames wrote:

> But we took two seg faults, so I moved us back to 2.0.24. The URL was
> http://search.apache.org/ .  This was a POST request.  The dumps are
> /usr/local/apache2.0.26-debug/corefiles/httpd.core.1 and .2, and they
> look the same.

This looks like an easy one.  Patch in a few minutes.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA