Stas Bekman wrote:
I think this misleading error is really a bug in Apache:
I agree.
[Mon Apr 26 15:28:44 2004] [error] server reached MaxClients setting,
consider raising the MaxClients setting
It sounds like a one-off bug to me. It reports that error when the
number of workers is the same as
moving to [EMAIL PROTECTED]
Stas Bekman wrote:
I think this misleading error is really a bug in Apache:
I agree.
[Mon Apr 26 15:28:44 2004] [error] server reached MaxClients setting,
consider raising the MaxClients setting
It seems to happen when the parent is
trying to increase the
Alexis Huxley wrote:
[Mon Feb 16 23:35:33 2004] [warn] (97)Address family not supported by protocol:
get socket to connect to listener
[Mon Feb 16 23:35:34 2004] [warn] (97)Address family not supported by protocol:
get socket to connect to listener
Ok, it did it again. Here's the
Ben Laurie wrote:
Jeff Trawick wrote:
Jim Jagielski wrote:
I'd like to float the idea of releasing 1.3.30 soonish.
one question: who would support putting the 1.3 versions of
mod_backtrace and mod_whatkilledus in experimental?
+1.
+1
Greg
Jeff Trawick wrote:
William A. Rowe, Jr. wrote:
At 10:22 AM 11/1/2003, [EMAIL PROTECTED] wrote:
trawick 2003/11/01 08:22:16
backport this from Apache 2.1-dev:
Set the scoreboard state to indicate logging prior to running
logging hooks so that server-status will show 'L' for hung
William A. Rowe, Jr. wrote:
At 04:34 PM 2/6/2004, [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
And perhaps I'm going way off in left field here, but why should this be
user-configurable at all? Shouldn't the (for example) server-status
handler know itself that it is a virtual handler, and
Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
or Joshua's virtual keyword on Location , which I like better
the more I think about it.
ooops... s/Joshua/André/
but Joshua has excellent points about virtualness being a property
of the handler. Yes, the server-status handler should know that
William A. Rowe, Jr. wrote:
At 02:11 PM 2/9/2004, [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
Modules can do that today with some very trivial code...
I think I see a problem. No doubt it could be made to work with a simple tweak.
SetHandler in the location container sets the handler
moving to dev@ ... this deserves wider attention IMO
Geoffrey Young wrote:
one thing I was wondering about was the interaction between your patch an
mod_alias. just by following the code without testing, it seems like either
mod_alias needs to unset the outside_filesystem flag for things like
[EMAIL PROTECTED] wrote:
* buildconf: Clean autoconf cache after running autoconf too.
+# Remove autoconf 2.5x's cache directory
+rm -rf autom4te*.cache
yay!
Greg
[EMAIL PROTECTED] wrote:
or Joshua's virtual keyword on Location , which I like better the
more I think about it.
ooops... s/Joshua/André/
but Joshua has excellent points about virtualness being a property of the
handler. Yes, the server-status handler should know that it is virtual, but the
William A. Rowe, Jr. wrote:
At 12:17 PM 2/5/2004, Joshua Slive wrote:
I do, however, agree that doing a directory-walk on virtual resources is
not nice. But my opinion is that virtualness is a property of the
resource, and hence should be designated when selecting the resource.
That is why I
Thanks for the feedback, Will.
William A. Rowe, Jr. wrote:
At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote:
But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether
Joshua Slive wrote:
(without closer looking at the code)
I'd suggest rather
Location [virtual] /uri-path
/Location
where the virtual keyword defines that the location is independent from
filesystem.
Perhaps I'm misunderstanding the issue, but neither of these make sense to
me. It is not really
Jeff Trawick wrote:
The buglet was that prctl() was issued always when available, when goal
(to be consistent with httpd 2.x) was to only issue it if admin has
coded CoreDumpDirectory.
+1 - reviewed and tested.
Greg
I had some offline feedback for my previous Location speeder-upper which I
though had merit. That patch skips the directory walk when it detects a
SetHandler directive inside of a Location block. The jist of the criticism was
that some user might have a Location block with a URI that overlaps
Brian Akins wrote:
How wrong would it be to have a map_to_storage that simply filled out
r-finfo and returned OK (or the appropriate error) always? IE, no
directory or file walk. From what I understand, Directory and File
directives would be useless, but Location would still work. Is this
Jeff Trawick wrote:
See http://www.apache.org/~trawick/exception_hook_13.html
There is a small patch to Apache 1.3 required to make the sample modules
work. This is analogous to the toys using the Apache 2.1 exception hook
which are described at
I'm interested in doing some scalability testing with worker on Linux to see
what the O(1) scheduler and new pthread library buys us, and what happens with
different values for ThreadsPerChild. I decided to use a simple handler that
just nanosleep()s for a variable amount of time controlled by
Geoffrey Young wrote:
...which is the same way we enable mod_status and mod_info. The key
thing here is that the URIs to access a Location enabled handler do not
map to the filesystem, so the directory walk is a waste of cycles. So
what can we do about it?
isn't that what map_to_storage is
Bill Stoddard wrote:
WHat happens if the handler DECLINES the request
My guess is that the default handler will be called, try to open a non-existant
file and send back a 404. I'll find out.
and do we care?
If it seg faults, violates protocol or something similar, I care. Other than
that I
[EMAIL PROTECTED] wrote:
Bill Stoddard wrote:
WHat happens if the handler DECLINES the request
My guess is that the default handler will be called, try to open a
non-existant file and send back a 404. I'll find out.
and do we care?
If it seg faults, violates protocol or something similar,
Bill Stoddard wrote:
WHat happens if the handler DECLINES the request
My guess is that the default handler will be called, try to open a
non-existant file and send back a 404. I'll find out.
Make sure file 'silly' exists in documentroot and make sure it has
access protections coded in a
Geoffrey Young wrote:
Bill Stoddard wrote:
My not so well formed thoughts are that if a module claims it should
handle a request based on a SetHandler directive in a Location
directive, the server should not allow that handler to DECLINE the
request. Putting it another way, if the handler claims
Colm MacCarthaigh wrote:
Not entirely serious, but today, we actually hit this, in production :)
The hardware, a dual 2Ghz Xeon with 12Gb RAM with Linux 2.6.1-rc2 coped,
and remained responsive. So 20,000 may no longer be outside the realms
of what administrators reasonably desire to have.
Jean-Jacques Clar wrote:
I never used any profiling
tools on Linux,
but will like to learn as much as possible in that field.
Since I have to start from scratch, Is oprofile the best one or do you
have any
other suggestions?
oprofile is my favorite for Linux because:
* it's open source and the
Jean-Jacques Clar wrote:
Attached are 2.0.48 numbers on RH AS 2.1 and 3.0.
Apache is build with worker MPM and default options on both versions.
Thanks for posting these measurements. I was happy to see that performance
stays pretty flat as the system got overloaded. The AS 3.0 8 CPU curve
+1 here too.
It's bad enough to have a problem where we need a dump, but much worse when we
can't get a dump without jumping thru hoops.
Greg
Jeff Trawick wrote:
configure-time checks would used to check for availability (certain
Linux only); the syscall would be made in the same situations
Joshua Schnee wrote:
I am attempting to set up the latest Apache server and RHEL 64bit to use
in a Specweb99 run and am running into cgi issues. I am very new to
Apache, and am having difficulty getting apache to run/use/find my
cgi-script. Static content works fine, but I am getting improper
Jeff Trawick wrote:
(Lots of structures aren't arranged to minimize or make available for
future use the inevitable padding, but the scoreboard is one where we
potentally have a great number of them in shared memory and also where
changing the size of the structure can break some modules.)
Ian Holsman wrote:
this commit reminds me..
weren't we going to do something similiar to this in 2.1 for the default
file handler? (replace the 'stat' with a 'fstat')
Will .. do you remember the whole details? it was something about
putting the handle into the request_rec or something
I think
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
I enabled the POST transactions, and all of a sudden, the apache process is
now hung (this is first time I'm seeing this behaviour).. The stack is :
(gdb) t 21
[Switching to thread 21 (system thread 29207)]
#0 0xc0306850:0 in _semop_sys+0x30
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
I think I found the problem (.. and it's not the cgid exiting problem).
The problem was because the default Listen Backlog in mod_cgid was a little
small (100 outstanding connections). I got the following tusc log for the
httpd processes :
{62717}
mod_suexec.c
mod_so.c
Greg
ServerRoot /home/gregames/apache/httpd-2.0.48/built
DocumentRoot /spec_docroot
User webuser
Group staff
LoadModule specweb99_module modules/mod_specweb99.so
LoadModule status_module modules/mod_status.so
LoadModule info_module modules/mod_info.so
LoadModule
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Hi Greg,
The recent set of discussions prompted me to get some Apache numbers
out there - and when I started with the SPECweb99 run, I experienced a major
hang in the Apache, and the cgid daemon getting killed (I don't know how).
Have you
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
cgid should _never_ exit without something in the error log.
I tried attaching tusc to the cgi daemon - but since the daemon dies at a
random time, my log file was getting too full, and I had to just stop it.
Why not just let tusc write to a
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Hi Greg,
The recent set of discussions prompted me to get some Apache numbers
out there - and when I started with the SPECweb99 run, I experienced a major
hang in the Apache, and the cgid daemon getting killed (I don't know how).
Have you
making public per Madhu
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
I'm using 2.0.48 and also back-ported the cgid-restart patch to 2.0.48. I
got a little further on the issue : The Apache hang is definitely caused by
the cgid exiting.
cgid should _never_ exit without something in the error
William A. Rowe, Jr. wrote:
On Mon, 20 Oct 2003, Jim Jagielski wrote:
* isn't ap_die() broken with recognizing recursive errors
Have you had a chance to run it through the perl-framework testsuite?
If so I'd give it +.5.
Does the perl test suite check error handling at all? (just curious)
William A. Rowe, Jr. wrote:
At 03:17 PM 10/20/2003, Aryeh Katz wrote:
I have an input filter that might need to reinvoke the handler that inserted this
input filter (this time with the filter removed).
Do not attempt to remove a filter once it's inserted, simple force it to be inert.
hmmm?
Joe Orton wrote:
Graceful restarts can be really slow in 2.0 with prefork... the parent
is making a dummy connection on the pod MaxClients times, rather than a
connection for as many children as it has had; is that really necessary?
We've had problems in this area in the past (not necessarily in
Stas Bekman wrote:
Also we need to have the vhost info in the score, otherwise request URI
info is not quite useful on the system with several vhosts, since you
can't tell which vhost it was invoked from.
hmmm? AFAIK vhost is working fine - see http://apache.org/server-status
Greg
Thom May wrote:
+1 from Linux: prefork/perchild/threadpool/worker all build
prefork/worker both work fine in production environments.
The new httpd is looking good on www.apache.org (minotaur) since 09-Oct-2003
15:08:33 PDT. A few minutes before this, we had about a one minute
Jeff Trawick wrote:
a cgi script can write this in the response header: Status: nnn... it
would sometimes be nice to know if the script did such a thing...
(like a current problem I'm working on: where the heck did the 500 come
from for this CGI; there's nothing in the error log and the few
Greg Stein wrote:
ap_rput* should be torched as well.
what about simplicity? how many lines of code are required for an alternative?
Greg
William A. Rowe, Jr. wrote:
I recall some discussion that the walk-through-every-registered-hook-provider
to resolve the handler is a pretty slowish/crufty way to handle that part of
the request processing. Especially if everyone sets up the handler up-front
in the various request preprocessing
Sander Striker wrote:
Hi,
I tagged the trees today, as STRIKER_2_0_48_PRE1 and STRIKER_2_1_0_PRE1
respectively. I'll try and get some tarballs up for testing, but
for now, please test the tag.
Looks good on RedHat 9 with worker. I didn't do anything special to change
thread libraries, so I
Sander Striker wrote:
Hi,
I've tagged the tree with STRIKER_2_0_47_PRE1. Testing would be
greatly appreciated.
will do.
I haven't been following the lists too closely lately (day job + personal
upheaval) so I appreciate the off list email.
Cheers,
Greg
Sander Striker wrote:
I've tagged the tree with STRIKER_2_0_47_PRE1. Testing would be
greatly appreciated.
The new httpd has been running live on daedalus since Thursday, 03-Jul-2003
11:48:45 PDT. So far, so good.
Greg
Lothar ? wrote:
does anyone know how to increase the time apache will wait
before sending a SIGKILL to cgi-processes?
(Or to change the kill-policy used with subprocesses?)
problem background:
I'm using BerkeleyDB from my perl-cgi-scripts, but I don't know how
to close the database in case of
Pablo Yaggi wrote:
It doesn't dump anything, i have this
CoreDumpDirectory /tmp/
and it dumps nothing there.
ok, that looks good so far...
What I saw is that a new process for the site (user pablo)
is being started about 2 seconds all the time and
each process logs what I mention before, so I
[EMAIL PROTECTED] wrote:
There is a fix in the open source version of 2.0.46
http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz
...which allows coredumps on Linux when you start httpd as root and code
CoreDumpDirectory in httpd.conf. If you start httpd as non-root, it
should just work
Pablo Yaggi wrote:
No, it was running as less privileged user ,
and the version Extranet is just somthing mandrake puted there,
I'm recompiling mandrakes rpms, maybe there's some patch there that stops the dumps, i'll try
to rebuild the source.
you might want to have a look at my other post where
Marc M. Adkins wrote:
The ap_hook_handler() call
does not specify the handler key from the corresponding AddHandler
configuration directive. As a consequence, the specified handler function
must look at and accept or decline each request.
yes, you are right. IMO that sucks, for a number of
Pablo Yaggi wrote:
besides is prefork using threads ?
prefork does not use threads.
i installed a server with perchild and this is a strip from my error log:
[Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal Segmentation fault (11)
do you have a coredump? We the
Juan Rivera wrote:
Have you guys ever considered making the size of the socket read buffer
configurable (default is 8K)?
not really, is it a problem?
Greg
Juan Rivera wrote:
I'm seen this problem with a SOCKS protocol module I wrote.
I'm including a patch that fixes this problem. It does what I mentioned
below. In the input filter, it moves the buckets rather than creating a
new brigade and then concatenate. In the output filter it splits the
[EMAIL PROTECTED] wrote:
Juan Rivera wrote:
I'm seen this problem with a SOCKS protocol module I wrote.
I'm including a patch that fixes this problem. It does what I
mentioned below. In the input filter, it moves the buckets rather than
creating a new brigade and then concatenate. In the
Juan Rivera wrote:
Here is why I'm asking. I wrote a SOCKS proxy module. It has two
connection records, one for the client and one for the backend server.
When I received data I pass it to the other side with a flush at the
end. It works fine with one problem. The core output filter splits the
Here is an strace of the static portion of the SPECWeb99 benchmark.
http://www.apache.org/~gregames/strace.spec_static
This includes two keepalive connections with multiple requests on each
connection, with Apache 2.0.43 running on a Red Hat 7.2 box. The number
preceding the syscall
Jeff Trawick wrote:
Modified:modules/http http_protocol.c
Log:
don't apply byte ranges to redirects, error documents, etc.
This needs to be listed in CHANGES.
done.
Greg
Joshua Slive wrote:
4. Even deadelus is not a guarenteed working site at the moment.
I hope that was a Freudian slip. It seems pretty alive this morning.
Greg
...at Sunday, 27-Oct-2002 07:07:35 PST, to install a couple of patches on top of
2.0.43 to fix:
* junk left in the scoreboard after a graceful restart with smaller MaxClients
* byterange filter was applying ranges to redirect responses
Greg
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
I noticed that there were some places where u_int32_t is being used instead
of apr_uint32_t. Is it purposefully done OR is it one of those Oh, the apr
interface changed stuff ?.
Anyways, I've included a patch that atleast gets the module to
busted. I'll work up a patch for
daedalus to bail out of the byterange filter if the status isn't 200 HTTP_OK
upon entry, then look at the RFC and 1.3 to see if that's the right solution.
Greg
[gregames@gandalf netcat]$ cat redirect.no_br
HEAD /dist/httpd/binaries/win32/apache_2.0.43-win32-x86
check this out:
[gregamesdaedalus gregames]$ grep 194.65.14.76 .*binaries.* 416
/logs/www/weblog | wc -l
69763
I asked root to block this IP for a while, because we are getting a couple of
these every second. I suspect there's an httpd bug here as well as a looping
client. We shouldn't
[EMAIL PROTECTED] wrote:
Pier Fumagalli wrote:
I'm still seeing erratic ssh response. Is there some way to monitor network
bandwidth utilization in real time? I wonder if we are maxing out our NICs
this morning? That would make the big downloads take longer, using up more httpd
I've redirected more content to nagoya due to our recent performance problems on
daedalus. Namely, jakarta.apache.org/builds/jakarta-tomcat-40/release,
jakarta.apache.org/builds/jakarta-ant/release, and the three most popular httpd
source tarballs under www.apache.org/dist/httpd/
/dist/ to point to
the proper place on nagoya, and bumping MaxClients from 775 to 800.
Please let me know if there are problems due to the Redirects I added. There is
a list of the top 20 bandwidth eaters from yesterday at
http://www.apache.org/~gregames/top20.bytes_served.10.20 . I suppose
amit athavale wrote:
I am using Apache 2.0 with prefork MPM. There is some external program which adds
VirtualHosts to httpd.conf dynamically and send SIGUSR1 to a process with pid = {pid
in httpd.pid}. Immediately after this, that external program sends some HTTP request
which should
William A. Rowe, Jr. wrote:
What's the penalty for stable/development trees? Users don't have
the development code (at least not many) for some time, until the
development tree becomes GA quality. But that's how it should be,
and that's the only way we will ever find 1.3 adopters moving to
amit athavale wrote:
I am using Apache 2.0 with prefork MPM. There is some external program which adds
VirtualHosts to httpd.conf dynamically and send SIGUSR1 to a process with pid = {pid
in httpd.pid}. Immediately after this, that external program sends some HTTP request
which should resolve
William A. Rowe, Jr. wrote:
for testing from http://httpd.apache.org/dev/dist/ in your preferred
.tar.gz, .tar.Z or -win32-src.zip format (-win32-src.zip containing
the msvc makefiles.)
It's been running for about 20 minutes on daedalus - looks fine.
Greg
Brian Pane wrote:
One of the known limitations of the current mod_mem_cache
code is that it uses a single global mutex to serialize
cache additions and deletions.
So the other alternative I've been thinking of is to
use an algorithm based on atomic compare-and-swap
operations to allow
/usr/local/apache2.0.42/corefiles/httpd.core.2
#0 bndm (n=0x281f7351 !--#, nl=5,
h=0x28249000 Address 0x28249000 out of bounds, hl=8533, t=0x80e28f4)
at mod_include.c:299
#1 0x281f1d50 in find_start_sequence (dptr=0x8144038, ctx=0x813f728,
bb=0x814d8c0, do_cleanup=0xbfbff5ac) at
=0x814d8c0, do_cleanup=0xbfbff5ac) at mod_include.c:480
Looks like mod_include is an innocent victim this time.
[gregames@daedalus apache]$ ls -l corefiles/httpd.core.2
-rw-r--r-- 1 nobody wheel 1736704 Sep 25 09:43 corefiles/httpd.core.2
[gregames@daedalus apache]$ uptime
9:57AM up 1 day, 6 mins
[EMAIL PROTECTED] wrote:
Sander Striker wrote:
Hi,
Done enough testing to say:
+1 for GA
I reserve my judgement until it has run longer without problems on daedalus.
I'm now confident that 2.0.42 is stable.
Greg
Cliff Woolley wrote:
Has anybody torture tested graceful restarts lately? I only ask because
we just got a PR that gave me that sinking feeling. Maybe not a real
problem, but just figured I'd ask.
They work on daedalus with prefork. But that's typically just once a night -
not sure if
Sander Striker wrote:
Hi,
Done enough testing to say:
+1 for GA
Having been burned before, I reserve my judgement until it has run longer
without problems on daedalus. It's been up less than 22 hours so far; I'll be
satisfied if we make it to 48 hours when at least 24 of those are
Jeff Trawick wrote:
This is the same fix which was applied to APR prior to Apache 2.0.40's
release. With 2.0, the problem was first reported on HP-UX/Itanium.
With 1.3, the problem was first reported on Linux/zSeries.
I also removed a bogus comment. In fact, it is normal for union semun
Brian Pane wrote:
[EMAIL PROTECTED] wrote:
__pthread_alt_unlock() loops through a list of threads that are blocked on a
mutex to find the thread with the highest priority. I don't know which mutex
this is; I'm guessing it's the one associated with worker's condition variable.
The
Sander Striker wrote:
I'd like to move to 2.0.42 right away and roll that.
2.0.42 would have only one thing different from
2.0.41 and that is the mod_dav fix that was committed.
It's runing live on daedalus and looks fine.
Thoughts or objections?
Thanks for all your RM efforts.
Greg
Ian Holsman wrote:
Hi Greg,
we are about to start into the wild wild world of linux, and I was
wondering if you have any hints on what patches you would go with for a
custom kernel to get maximum performance.. stuff like ingo's O(1)
scheduler and the like..
I'm glad you asked, since
Sander Striker wrote:
Hi,
I tagged the tree today as STRIKER_2_0_41_PRE1. I'll do some
testing this weekend myself and will retag for release after
I get some positive feedback on this tag.
Greg, could you bump daedalus to this tag next week to see how
it holds?
Sure. I was swamped
Ian Holsman wrote:
[EMAIL PROTECTED] wrote:
jerenkrantz2002/09/05 00:31:14
Modified:.CHANGES
modules/http mod_mime.c
Log:
Add ModMimeUsePathInfo directive.
+int use_path_info;/* If set to 0, only use filename.
+
Peter Van Biesen wrote:
Hello,
when I set the LogLevel to info, I get a lot of message like the one in
de subjectline, is this normal ? Has anybody else observed this ?
I think those messages are common for a production site with a lot of users and
LogLevel info. We use LogLevel warn on
86 matches
Mail list logo
