reads in mod_cgi: eof wasn't treated as an error condition when
reading the script headers, so we were delivering a 200 when a
CGI script produced no output.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94342 13f79535-47bb-0310-9956-ffa450edef68
Obtained from:
Submitted by: Paul J. Reder
Reviewed by:
Remove the MPM_SYNC_CHILD_TABLE macro since there is no longer a scoreboard
file that needs to be synched.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94308 13f79535-47bb-0310-9956-ffa450edef68
and completely contained in a file (SCOREBOARD_FILE) has been
removed. This does not affect scoreboards which are *mapped* to
files using named-shared-memory at all. This implies that scoreboards
must be based, at some level, on native shared memory (mmap, shm_open,
shmget, whatever), but the code has assumed that for quite awhile
now. Having the scoreboard be *based* on a file makes no sense today.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94306 13f79535-47bb-0310-9956-ffa450edef68
Add an allocator-passing mechanism throughout the bucket brigades API.
From Apache's standpoint, the apr_bucket_alloc_t* used throughout a given
connection is stored in the conn_rec by the create_connection hook. That
means it's the MPM's job to optimize recycling of apr_bucket_alloc_t's --
the MPM must ensure that no two threads can ever use the same one at the
same time, for instance.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94304 13f79535-47bb-0310-9956-ffa450edef68
quick handlers to optionally do a lookup rather than actually
serve content. This is the first of several changes required fix
several problems with how quick handlers work with subrequests.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94240 13f79535-47bb-0310-9956-ffa450edef68
get MaxRequestsPerChild to work again by allowing the main thread of
a child to be interrupted by one of the other threads in the process
this should get graceful termination to work after encountering one of
the various possible error conditions in the listener and worker threads
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94232 13f79535-47bb-0310-9956-ffa450edef68
when the .conf file is missing or horribly corrupt. Move those actions
into the rewrite args phase so we don't trip over a missing .conf file,
we couldn't care less if we are stopping/uninstalling Apache.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94189 13f79535-47bb-0310-9956-ffa450edef68
cases in the core_output_filters where there was a problem, and the core
returned an error code instead of an HTTP status code. This keeps us from
putting status codes like 32 and 104 in the access log.
Submitted by: Ryan Morgan <rmorgan@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94143 13f79535-47bb-0310-9956-ffa450edef68
threads could exit even though there were connections waiting in the
queue.
Now, for a graceful restart the worker threads won't exit until they
are told that the queue has been drained and no more connections will
ever be added.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94106 13f79535-47bb-0310-9956-ffa450edef68
go away before the workers... introduce separate XXX_may_exit flags
for our different categories of threads so that a future fix for
graceful shutdown can terminate them in the right order
rename signal_workers() to signal_threads() and give it a parameter
so it knows whether or not termination should be graceful
this commit doesn't change the behavior in any noticeable way; the
flags used to tell threads to go away are still set at about the same
time
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94095 13f79535-47bb-0310-9956-ffa450edef68
carriage return on Win32/OS2, and modify the \r \n escaping to account
for the fact that Win32/OS2 don't pass these characters through a true
argv[] mechansim; replace them with a whitespace since they effectively
are for most applications.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94070 13f79535-47bb-0310-9956-ffa450edef68
its help entry. Requires the use of a extern string rather than a function
call for the initialization to be valid in the macro (Thx to Jeff!).
In the meantime, bump down the error logging until we deal with true
default and configured setting information ala 1.3.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94062 13f79535-47bb-0310-9956-ffa450edef68
of trying to take over scoreboard slots that aren't going to be released
(we could also be stalled while taking over slots if a thread in child
gracefully terminating is serving a long-running request)
update a comment describing the sicko state to remove any information
I'm not absolutely sure of
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94059 13f79535-47bb-0310-9956-ffa450edef68
the admin regarding valid values for AcceptMutex. Should also
tell 'em what "default" actually maps to, but that can wait.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94055 13f79535-47bb-0310-9956-ffa450edef68
of apr_socket objects already destroyed by their cleanups, and in any
case they now live in invalid memory. Extend their lifetimes.
This implies that the process pool grows on every restart for no good
reason. One possible solution is to let the old pconf survive until
the new pconf is alive. Another is to create the listeners in a subpool
of process->pool, destroyed after the old_listeners are closed.
Either which way, a better solution exists, but this closes the immediate
bug. [How haven't we been segfaulting in unix on restarts before this
patch, gurus?]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94048 13f79535-47bb-0310-9956-ffa450edef68
scoreboard exists. I suspect this should be a general cleanup as well
[at the end of ap_create_scoreboard.] But calling ap_run_pre_mpm with
the process->pool should take care of a clobbered scoreboard shm on
graceful restart.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94040 13f79535-47bb-0310-9956-ffa450edef68
cleanly at graceful restart time. This is a basic requirement of
reliable graceful restarts (the kind that won't drop connections).
This allows a future fix to make worker threads hang around until
they service all connections previously accepted by the listener
thread.
The old mechanism of doing a dummy connection to wake up the
listener thread in each old child process didn't work. It didn't
guarantee that (in the main thread) the byte was read from the pod
and global variables were set before the listener thread grabbed
the connection. It didn't guarantee that a child process in the
new generation didn't get some of the dummy connections.
Rather than burn extra syscalls adding a unique socket or pipe
to the poll set (and breaking single listen unserialized accept
in the same change), this uses a signal sent from the main thread
to the listener thread to break it out of the poll or accept.
(We don't worry about breaking it out of the optional mutex because
the child process holding the mutex will break out of poll/accept
and release the mutex, allowing a child blocked in the mutex to
get it. Eventually all children blocked in the mutex will come
out.)
Since the listener thread now exits reliably, the main thread
joins it.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94031 13f79535-47bb-0310-9956-ffa450edef68
it is still trying to create worker threads
previously, after a non-graceful restart followed by a terminate
you could see a bunch of log messages showing the parent repeatedly
sending SIGTERM and finally SIGKILL to one or more children...
with this change, the sequence of messages should stop very soon
add a comment to start_threads() describing a current problem
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94030 13f79535-47bb-0310-9956-ffa450edef68
it is helpful to distinguish between a failure creating the
first thread (listener) vs. a failure creating one of n
worker threads
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94025 13f79535-47bb-0310-9956-ffa450edef68
the pod... the child processes need to know that it isn't a graceful
termination and they shouldn't wait for old connections to finish
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94024 13f79535-47bb-0310-9956-ffa450edef68
in the situation where MaxClients is very high but
much fewer servers are actually started at the time of the
restart.
The way we notify an entire generation to die at once is
changed so that we don't have to use the pod (and deal with
the ease of filling the kernel pipe buffer).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93999 13f79535-47bb-0310-9956-ffa450edef68
