httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <>
Subject Re: Syntax error during HTTP2 reload
Date Wed, 08 Jun 2005 14:47:18 GMT
Nope, there are still in the usual location /etc/apache2/server-tuning.conf

I didn't understand the problem evocated by Jeff since the Apache
server used in Suse is the one from the ASF (in contrario of IBM HTTP
Server powered by Apache found on iSeries and pSeries which derive
from ASF code but contains many specific code).

Suse us ASF source tarball, and ASF patches, so what's the problem ?

Suse only use a different configuration system but nothing special or
exotic, just a reworked and splitted configuration loaded with

2005/6/8, Dr. Peter Poeml <>:
> On Tue, Mar 01, 2005 at 05:57:39AM -0500, Jeff Trawick wrote:
> > On Tue, 1 Mar 2005 10:04:03 +0100, Henri Gomez <> wrote:
> > > Nobody to wonder about this bug ?
> >
> > sure; note that you're using old code (2.0.49/2.0.49) which isn't
> > supported here anyway since we don't know what code is in it (SuSE)
> (sorry about the late reply)
> The apache shipped by SUSE is basically built from the pristine sources.
> A package named 2.0.49 would contain exactly version 2.0.49, except for
> - changes of configuration (I always complied 100% to the old license :)
> - security fixes, which are added later (inevitably)
> - and, since the codebase was relicensed under the Apache License 2.0
>   and it is now allowed to do that, an occasional important fix from
>   later released versions of the respective branch
> > > > It's seems the problem occurs will Apache receive the SIGUSR1 and is
> > > > also handling requests  (forwared to Tomcat via mod_jk 1.2.5 and
> > > > 1.2.6).
> >
> > the config parsing happens in the parent process, which shouldn't be
> > impacted by active requests
> >
> > seems fairly likely that there is memory corruption which occurs at
> > restart time (a relatively common time to find out about such
> > badness)...  I'd bet my money on it being caused by a module not
> > distributed as part of Apache httpd...
> I was not able to reproduce the problem but I wonder if the problem is
> that the BrowserMatch directives are located in an unusual place in our
> configuration. They are placed before the LoadModule statements. But
> BrowserMatch is provided by the module mod_setenvif, so they should
> probably be put after loading that module. However, I wonder why the
> server does not error out about this on normal startup, but only during
> the graceful restart, and only in rare setups.
> Henri, did you ever try to move the BrowserMatch directives further down
> in the config? (sorry if you alread did so, and my memory is just too
> weak)

View raw message