Re: [Patch] Reliable error logs for trunk
Hi Rüdiger,
first thanks for reviewing.
On 17.01.2009 18:02, Ruediger Pluem wrote:
On 01/16/2009 12:21 AM, Rainer Jung wrote:
This difference goes back to pre 1.3 httpd.
The patch at
http://people.apache.org/~rjung/patches/reliable_error_log.patch
Just some quick comments below
Index: server/log.c
===
--- server/log.c(revision 734457)
+++ server/log.c(working copy)
@@ -319,20 +333,28 @@
int rc;
if (*s->error_fname == '|') {
-apr_file_t *dummy = NULL;
+piped_log *pl;
+fname = ap_server_root_relative(p, s->error_fname + 1);
+if (!fname) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP, APR_EBADPATH, NULL,
+ "%s: Invalid error log path '%s'.",
+ ap_server_argv0, s->error_fname);
+return NULL;
+}
+
/* Spawn a new child logger. If this is the main server_rec,
* the new child must use a dummy stderr since the current
* stderr might be a pipe to the old logger. Otherwise, the
* child inherits the parents stderr. */
-rc = log_child(p, s->error_fname + 1,&dummy, is_main);
-if (rc != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_STARTUP, rc, NULL,
- "Couldn't start ErrorLog process");
+pl = piped_log_open(p, fname, is_main);
+if (pl == NULL) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
+ "%s: Couldn't start ErrorLog process '%s'.",
+ ap_server_argv0, fname);
return DONE;
Why not keeping the old way if
#ifndef AP_HAVE_RELIABLE_PIPED_LOGS?
I still need to investigate, what actually happens in the non-reliable
case. But yes, for lowest risk, we could keep calling log_child() in
that case, until we understand it better. On the long term I have a
preference to keep access and error logging in both cases consistent.
}
-
-s->error_log = dummy;
+s->error_log = ap_piped_log_write_fd(pl);
}
#ifdef HAVE_SYSLOG
@@ -953,13 +992,26 @@
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
"piped log program '%s' failed unexpectedly",
pl->program);
-if ((stats = piped_log_spawn(pl)) != APR_SUCCESS) {
+
+/* If special_stderr is non-zero, we need to get the write
+ * end of the pipe back from stderr before spawning. */
+if ((plw->special_stderr&& (stats =
apr_file_dup(&ap_piped_log_write_fd(pl),
+ stderr_log,
pl->p))
+!= APR_SUCCESS) ||
+ ((stats = piped_log_spawn(plw)) != APR_SUCCESS) ||
+/* If special_stderr is non-zero, we need to close the write
+ * end of the pipe after spawning, because we write to it via
+ * stderr. */
+ (plw->special_stderr&& (stats =
apr_file_close(ap_piped_log_write_fd(pl)))
+!= APR_SUCCESS)) {
I know that this is always a difficult and confusing part, so maybe it just
confused me again,
but why do we need to do the above?
ap_piped_log_write_fd(pl) should have the correct fd already because in
ap_open_logs we just
duplicate the write side of the pipe to stderr and in all other cases (not main
server error log)
ap_piped_log_write_fd is just fine anyways.
It *is* confusing.
Step 1:
---
open_error_log() calls
piped_log_open() calls
apr_file_pipe_create_ex()
We get 2 FDs, say FD9 (read) and FD10 (write).
Step 2:
---
piped_log_open() calls
piped_log_spawn() calls
apr_procattr_child_in_set()
We have 2 additional FDs, say FD11 and FD12, FD11 pointing to the same
end of the pipe as FD9 and FD12 as FD10.
Step 3:
---
piped_log_spawn() calls
apr_proc_create()
This closes FD11.
Step 4:
---
piped_log_spawn() calls
apr_file_close(procnew->in)
This closes FD12.
Now we have a separate process and the parent only has 2 additional FDs,
which can be used to communicate to the external process and to recreate it.
The next steps do only happen for the main error logger:
Step 5:
---
open_error_log() calls
apr_file_dup2(stderr_log, s_main->error_log, stderr_p)
s_main->error_log contains FD10, so the call lets FD2 (stderr_log) point
to the same pipe as FD10. FD9 and FD10 remain unchanged.
Step 6:
---
open_error_log() calls
apr_file_close(s_main->error_log)
FD10 gets closed, we only have FD2 and FD9 remaining,
ap_piped_log_write_fd(pl) is gone now!
So if we want to keep this behaviour, we need to recreate the write side
of the pipe from stderr in maintenance before spawning again (in the
main error logger case), and close it after spawning.
I tried using FD2 directly as the write side without du
Re: [Patch] Reliable error logs for trunk
On 01/18/2009 03:52 PM, Rainer Jung wrote:
> Hi Rüdiger,
>
> first thanks for reviewing.
>
> On 17.01.2009 18:02, Ruediger Pluem wrote:
>>
>> On 01/16/2009 12:21 AM, Rainer Jung wrote:
>>
>>> This difference goes back to pre 1.3 httpd.
>>>
>>> The patch at
>>>
>>> http://people.apache.org/~rjung/patches/reliable_error_log.patch
>>
>> Just some quick comments below
>>
>> Index: server/log.c
>> ===
>> --- server/log.c(revision 734457)
>> +++ server/log.c(working copy)
>> @@ -953,13 +992,26 @@
>> ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
>>"piped log program '%s' failed unexpectedly",
>>pl->program);
>> -if ((stats = piped_log_spawn(pl)) != APR_SUCCESS) {
>> +
>> +/* If special_stderr is non-zero, we need to get the write
>> + * end of the pipe back from stderr before spawning. */
>> +if ((plw->special_stderr&& (stats =
>> apr_file_dup(&ap_piped_log_write_fd(pl),
>> +
>> stderr_log, pl->p))
>> +!= APR_SUCCESS) ||
>> + ((stats = piped_log_spawn(plw)) != APR_SUCCESS) ||
>> +/* If special_stderr is non-zero, we need to close the write
>> + * end of the pipe after spawning, because we write to it
>> via
>> + * stderr. */
>> + (plw->special_stderr&& (stats =
>> apr_file_close(ap_piped_log_write_fd(pl)))
>> +!= APR_SUCCESS)) {
>>
>> I know that this is always a difficult and confusing part, so maybe it
>> just confused me again,
>> but why do we need to do the above?
>> ap_piped_log_write_fd(pl) should have the correct fd already because
>> in ap_open_logs we just
>> duplicate the write side of the pipe to stderr and in all other cases
>> (not main server error log)
>> ap_piped_log_write_fd is just fine anyways.
>
> It *is* confusing.
>
> Step 1:
> ---
>
> open_error_log() calls
>piped_log_open() calls
> apr_file_pipe_create_ex()
>
> We get 2 FDs, say FD9 (read) and FD10 (write).
>
> Step 2:
> ---
>
>piped_log_open() calls
> piped_log_spawn() calls
> apr_procattr_child_in_set()
>
>
> We have 2 additional FDs, say FD11 and FD12, FD11 pointing to the same
> end of the pipe as FD9 and FD12 as FD10.
>
> Step 3:
> ---
>
> piped_log_spawn() calls
> apr_proc_create()
>
> This closes FD11.
>
> Step 4:
> ---
>
> piped_log_spawn() calls
> apr_file_close(procnew->in)
>
> This closes FD12.
>
> Now we have a separate process and the parent only has 2 additional FDs,
> which can be used to communicate to the external process and to recreate
> it.
>
> The next steps do only happen for the main error logger:
>
> Step 5:
> ---
>
> open_error_log() calls
>apr_file_dup2(stderr_log, s_main->error_log, stderr_p)
>
> s_main->error_log contains FD10, so the call lets FD2 (stderr_log) point
> to the same pipe as FD10. FD9 and FD10 remain unchanged.
>
> Step 6:
> ---
>
> open_error_log() calls
>apr_file_close(s_main->error_log)
The call to apr_file_close happens in ap_open_logs not in open_error_log
and ap_open_logs is IMHO not called by piped_log_maintenance.
>
> FD10 gets closed, we only have FD2 and FD9 remaining,
> ap_piped_log_write_fd(pl) is gone now!
>
> So if we want to keep this behaviour, we need to recreate the write side
> of the pipe from stderr in maintenance before spawning again (in the
> main error logger case), and close it after spawning.
>
> I tried using FD2 directly as the write side without duping it, but that
> doesn't work.
Hm. F10 should still be open and untouched.
Regards
Rüdiger
Re: [Patch] Reliable error logs for trunk
On 18.01.2009 16:37, Ruediger Pluem wrote:
On 01/18/2009 03:52 PM, Rainer Jung wrote:
Hi Rüdiger,
first thanks for reviewing.
On 17.01.2009 18:02, Ruediger Pluem wrote:
On 01/16/2009 12:21 AM, Rainer Jung wrote:
This difference goes back to pre 1.3 httpd.
The patch at
http://people.apache.org/~rjung/patches/reliable_error_log.patch
Just some quick comments below
Index: server/log.c
===
--- server/log.c(revision 734457)
+++ server/log.c(working copy)
@@ -953,13 +992,26 @@
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
"piped log program '%s' failed unexpectedly",
pl->program);
-if ((stats = piped_log_spawn(pl)) != APR_SUCCESS) {
+
+/* If special_stderr is non-zero, we need to get the write
+ * end of the pipe back from stderr before spawning. */
+if ((plw->special_stderr&& (stats =
apr_file_dup(&ap_piped_log_write_fd(pl),
+
stderr_log, pl->p))
+!= APR_SUCCESS) ||
+ ((stats = piped_log_spawn(plw)) != APR_SUCCESS) ||
+/* If special_stderr is non-zero, we need to close the write
+ * end of the pipe after spawning, because we write to it
via
+ * stderr. */
+ (plw->special_stderr&& (stats =
apr_file_close(ap_piped_log_write_fd(pl)))
+!= APR_SUCCESS)) {
I know that this is always a difficult and confusing part, so maybe it
just confused me again,
but why do we need to do the above?
ap_piped_log_write_fd(pl) should have the correct fd already because
in ap_open_logs we just
duplicate the write side of the pipe to stderr and in all other cases
(not main server error log)
ap_piped_log_write_fd is just fine anyways.
It *is* confusing.
Step 1:
---
open_error_log() calls
piped_log_open() calls
apr_file_pipe_create_ex()
We get 2 FDs, say FD9 (read) and FD10 (write).
Step 2:
---
piped_log_open() calls
piped_log_spawn() calls
apr_procattr_child_in_set()
We have 2 additional FDs, say FD11 and FD12, FD11 pointing to the same
end of the pipe as FD9 and FD12 as FD10.
Step 3:
---
piped_log_spawn() calls
apr_proc_create()
This closes FD11.
Step 4:
---
piped_log_spawn() calls
apr_file_close(procnew->in)
This closes FD12.
Now we have a separate process and the parent only has 2 additional FDs,
which can be used to communicate to the external process and to recreate
it.
The next steps do only happen for the main error logger:
Step 5:
---
open_error_log() calls
apr_file_dup2(stderr_log, s_main->error_log, stderr_p)
s_main->error_log contains FD10, so the call lets FD2 (stderr_log) point
to the same pipe as FD10. FD9 and FD10 remain unchanged.
Step 6:
---
open_error_log() calls
apr_file_close(s_main->error_log)
The call to apr_file_close happens in ap_open_logs not in open_error_log
and ap_open_logs is IMHO not called by piped_log_maintenance.
Yes, sorry, it is ap_open_logs.
But nevertheless:
During startup or after restart we go through ap_open_logs() and thus
after startup or restart, the write side of the original pl is closed
and the pipe is written to via the duped FD in stderr.
More precisely ap_open_logs() calls open_error_log(), which returns
ap_piped_log_write_fd(pl) in s->error_log, and after return
ap_open_logs() calls apr_file_close(s_main->error_log) is s==s_main.
When killing the logger, piped_log_maintenance() gets called. It can now
not simply use pl, because the write side has been closed before in
ap_open_logs().
I tried to keep the startup behaviour during restart, so I dup stderr to
the write side in the maintenance function, spawn and close the write
side again.
FD10 gets closed, we only have FD2 and FD9 remaining,
ap_piped_log_write_fd(pl) is gone now!
So if we want to keep this behaviour, we need to recreate the write side
of the pipe from stderr in maintenance before spawning again (in the
main error logger case), and close it after spawning.
I tried using FD2 directly as the write side without duping it, but that
doesn't work.
Hm. F10 should still be open and untouched.
Just to make sure we are talking about the same. This gets only closed
for the main error logger. For all other error loggers and the access
loggers, there's no such complication.
Regards,
Rainer
Re: [Patch] Reliable error logs for trunk
Oups, need to clarify. On 18.01.2009 16:48, Rainer Jung wrote: During startup or after restart we go through ap_open_logs() and thus restart -> restart of httpd after startup or restart, the write side of the original pl is closed and the pipe is written to via the duped FD in stderr. More precisely ap_open_logs() calls open_error_log(), which returns ap_piped_log_write_fd(pl) in s->error_log, and after return ap_open_logs() calls apr_file_close(s_main->error_log) is s==s_main. is -> if When killing the logger, piped_log_maintenance() gets called. It can now not simply use pl, because the write side has been closed before in ap_open_logs(). I tried to keep the startup behaviour during restart, so I dup stderr to restart -> restart of a killed logger the write side in the maintenance function, spawn and close the write side again.
Re: [Patch] Reliable error logs for trunk
On 01/18/2009 04:48 PM, Rainer Jung wrote: > On 18.01.2009 16:37, Ruediger Pluem wrote: >> >>> >>> Step 6: >>> --- >>> >>> open_error_log() calls >>> apr_file_close(s_main->error_log) >> >> The call to apr_file_close happens in ap_open_logs not in open_error_log >> and ap_open_logs is IMHO not called by piped_log_maintenance. > > Yes, sorry, it is ap_open_logs. > > But nevertheless: > > During startup or after restart we go through ap_open_logs() and thus > after startup or restart, the write side of the original pl is closed > and the pipe is written to via the duped FD in stderr. Ahh. Now I got it. So your approach seems fine. Really very confusing :-). > > More precisely ap_open_logs() calls open_error_log(), which returns > ap_piped_log_write_fd(pl) in s->error_log, and after return > ap_open_logs() calls apr_file_close(s_main->error_log) is s==s_main. > > When killing the logger, piped_log_maintenance() gets called. It can now > not simply use pl, because the write side has been closed before in > ap_open_logs(). > > I tried to keep the startup behaviour during restart, so I dup stderr to > the write side in the maintenance function, spawn and close the write > side again. > >>> FD10 gets closed, we only have FD2 and FD9 remaining, >>> ap_piped_log_write_fd(pl) is gone now! >>> >>> So if we want to keep this behaviour, we need to recreate the write side >>> of the pipe from stderr in maintenance before spawning again (in the >>> main error logger case), and close it after spawning. >>> >>> I tried using FD2 directly as the write side without duping it, but that >>> doesn't work. >> >> Hm. F10 should still be open and untouched. > > Just to make sure we are talking about the same. This gets only closed > for the main error logger. For all other error loggers and the access > loggers, there's no such complication. Yes, this clearly was only valid for the main error log. Regards Rüdiger
Re: [VOTE] Release Apache HTTP server 2.3.1-alpha
On Fri, Jan 9, 2009 at 11:24 AM, Jim Jagielski wrote: > > On Jan 8, 2009, at 1:33 PM, Paul Querna wrote: > >> Vote closed with one -1, and no other votes. >> >> I guess 2.3.1 was DOA. >> >> I think the issues that killed it have been fixed in trunk. Thoughts on >> starting 2.3.2 early next week? >> > > +1 Is there any concern about the SNI support sitting in trunk? IIUC Joe's specific concern (testable failure) referenced in the stalled backport proposal are addressed by a later trunk commit, but there is still the spectre of similar but undiscovered cases and the issue of non-SNI clients. -- Eric Covener cove...@gmail.com
Re: [VOTE] Release Apache HTTP server 2.3.1-alpha
On 01/18/2009 05:23 PM, Eric Covener wrote: > On Fri, Jan 9, 2009 at 11:24 AM, Jim Jagielski wrote: >> On Jan 8, 2009, at 1:33 PM, Paul Querna wrote: >> >>> Vote closed with one -1, and no other votes. >>> >>> I guess 2.3.1 was DOA. >>> >>> I think the issues that killed it have been fixed in trunk. Thoughts on >>> starting 2.3.2 early next week? >>> >> +1 > > Is there any concern about the SNI support sitting in trunk? IIUC > Joe's specific concern (testable failure) referenced in the stalled > backport proposal are addressed by a later trunk commit, but there is > still the spectre of similar but undiscovered cases and the issue of > non-SNI clients. I guess this needs to be sorted out during our alpha releases phase and definitely be solved before releasing 2.4 GA. I currently don't worry about it for alpha releases. Maybe a good topic for the Hackathon at AC EU if Joe is there :-). Regards Rüdiger
Re: svn commit: r734703 - /httpd/httpd/trunk/modules/proxy/mod_proxy.c
On Thu, Jan 15, 2009 at 8:44 AM, wrote:
> Author: rpluem
> Date: Thu Jan 15 05:44:23 2009
> New Revision: 734703
>
> URL: http://svn.apache.org/viewvc?rev=734703&view=rev
> Log:
> * Set the error time if we set a worker in error mode.
>
> Modified:
>httpd/httpd/trunk/modules/proxy/mod_proxy.c
>
> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=734703&r1=734702&r2=734703&view=diff
Should the error time be set in set_worker_param() as well?
else if (*v == 'E' || *v == 'e') {
if (mode)
-> worker->status |= PROXY_WORKER_IN_ERROR;
else
worker->status &= ~PROXY_WORKER_IN_ERROR;
}
>
>
>
> ==
> --- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Thu Jan 15 05:44:23 2009
> @@ -1020,8 +1020,10 @@
> * We can not failover to another worker.
> * Mark the worker as unusable if member of load balancer
> */
> -if (balancer)
> +if (balancer) {
> worker->s->status |= PROXY_WORKER_IN_ERROR;
> +worker->s->error_time = apr_time_now();
> +}
> break;
> }
> else if (access_status == HTTP_SERVICE_UNAVAILABLE) {
> @@ -1031,6 +1033,7 @@
> */
> if (balancer) {
> worker->s->status |= PROXY_WORKER_IN_ERROR;
> +worker->s->error_time = apr_time_now();
> }
> }
> else {
>
>
>
--
Born in Roswell... married an alien...
Re: [Patch] Reliable error logs for trunk
pl = apr_palloc(p, sizeof (*pl)); pl->p = p; +pl->program = (program == NULL) ? NULL : apr_pstrdup(p, program); +pl->pid = NULL; Why is this needed now? Or was this just missed previously and is not really related to the reliable pipe usage of the error log? This was borked. Those fields do not exist in the struct when AP_HAVE_RELIABLE_PIPED_LOGS is not defined. I removed it.
Re: svn commit: r735093 - /httpd/httpd/trunk/server/mpm/winnt/child.c
On 16.01.2009 20:30, wr...@apache.org wrote: Author: wrowe Date: Fri Jan 16 11:30:42 2009 New Revision: 735093 URL: http://svn.apache.org/viewvc?rev=735093&view=rev Log: Introduce Win32 AcceptFilter handling. Divided into 3 classes, this implements the first two; * AcceptFilter 'data' - much as on Unix, accept will not complete until data is ready to be accepted. Unlike Unix, it will actually fetch the first bucket full of data from the tcp socket, and this patch implements passing that bucket into the core net brigade in front of the accepted socket. * AcceptFilter 'connect' - just as in Apache 2.2, accept will not complete until three way handshake is complete and the endpoints are resolved, and quickly grabs the endpoint addresses using the AcceptEx API (which some people have problems with). This will not be the default. * AcceptFilter 'none' [not yet implemented] - will be the traditional select/WSAAccept style processing for broken network socket stacks and more trivial tcp style connections. If AcceptEx appears to be a problem, the listener will be able to downgrade to 'none'. Modified: httpd/httpd/trunk/server/mpm/winnt/child.c I built trunk on XP today. When trying to run it, I get a restart loop for the child process, and the error log contains repetitions of: == [Sun Jan 18 19:20:42 2009] [notice] Apache/2.3.2-dev (Win32) configured -- resuming normal operations [Sun Jan 18 19:20:42 2009] [notice] Server built: Jan 18 2009 01:17:29 [Sun Jan 18 19:20:42 2009] [notice] Parent: Created child process 4556 [Sun Jan 18 19:20:43 2009] [notice] Child 4556: Child process is running [Sun Jan 18 19:20:43 2009] [notice] Child 4556: Acquired the start mutex. [Sun Jan 18 19:20:43 2009] [notice] Child 4556: Starting 150 worker threads. [Sun Jan 18 19:20:43 2009] [notice] Child 4556: Starting thread to listen on port 8000. [Sun Jan 18 19:20:43 2009] [error] (OS 10038)Ein Vorgang bezog sich auf ein Objekt, das kein Socket ist. : Child 4556: Encountered too many AcceptEx faults accepting client connections. Possible causes: dynamic address renewal, or incompatible VPN or firewall software. [Sun Jan 18 19:20:43 2009] [notice] (OS 10038)Ein Vorgang bezog sich auf ein Objekt, das kein Socket ist. : winnt_mpm: falling back to 'AcceptFilter none'. [Sun Jan 18 19:20:43 2009] [crit] (OS 10038)Ein Vorgang bezog sich auf ein Objekt, das kein Socket ist. : winnt_mpm: AcceptFilter 'none' is not yet supported (a classic WSAAccept logic). Use AcceptFilter 'connect' or 'data' in the meantime [Sun Jan 18 19:20:43 2009] [notice] Child 4556: Exit event signaled. Child process is ending. [Sun Jan 18 19:20:44 2009] [notice] Child 4556: Released the start mutex [Sun Jan 18 19:20:45 2009] [notice] Child 4556: All worker threads have exited. [Sun Jan 18 19:20:45 2009] [notice] Child 4556: Child process is exiting [Sun Jan 18 19:20:45 2009] [notice] Parent: child process exited with status 0 -- Restarting. == Since it is my first trunk build on Windows (and don't have VC6), I could have well made a mistake. Just wanted to let you know the result, in case you get the same. Regards, Rainer
Re: rotatelogs improvement
On 05.12.2008 22:41, Paul Querna wrote: glim wrote: Greetings. If this isn't being sent to the correct list, I apologize. Let me know and I'll go elsewhere. I'd like to make a minor improvement to rotatelogs and wanted to check with the list to see what would be most appreciated. "rotatelogs" as it stands now cannot rotate by time and date in a single invocation. I'm willing to write a patch to do this, but as I said, I'd like to find out what would best suit the community. ... Here are some options: 1. new syntax - pro: upgrade all options to use apr_getopt(), simple syntax, relatively small patch to rotatelogs. con: requiring flags for options will break unprepared users. I'd vote for doing this on trunk, 2.2.x backport can be skipped or rethought once we have it working. I just found these mails. I committed a change to trunk a few days ago, that allows rotation based on time *and* size. Since I wasn't sure about the configuration portability goals for 2.4, I chose to not introduce an incompatible syntax. So with trunk rotatelogs you can have: A) rotationtime|filesizeX [ offset ] or B) rotationtime filesizeX [ offset ] C) filesizeX rotationtime offset What will not work is: filesizeX rotationtime (would be interpreted as A with offset, the price we pay for compatibility). X above has to be exactly one of the characters B,K,M,G,T, especially it is not allowed to be empty. Regards, Rainer
Re: svn commit: r734703 - /httpd/httpd/trunk/modules/proxy/mod_proxy.c
On 01/18/2009 06:44 PM, Jeff Trawick wrote:
> On Thu, Jan 15, 2009 at 8:44 AM, wrote:
>
>> Author: rpluem
>> Date: Thu Jan 15 05:44:23 2009
>> New Revision: 734703
>>
>> URL: http://svn.apache.org/viewvc?rev=734703&view=rev
>> Log:
>> * Set the error time if we set a worker in error mode.
>
>
>> Modified:
>>httpd/httpd/trunk/modules/proxy/mod_proxy.c
>>
>> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=734703&r1=734702&r2=734703&view=diff
>
>
> Should the error time be set in set_worker_param() as well?
>
>else if (*v == 'E' || *v == 'e') {
> if (mode)
> -> worker->status |= PROXY_WORKER_IN_ERROR;
Well this is not possible here since error_time only lives in the shared
mem of the scoreboard (worker->s) and not in the config of a worker.
But worker->s is not initialized at this point of time (this is done in the
child_init hook).
The scoreboard area storing the error_time is initialized with 0, so
this variable has a defined value.
To be honest I do not get the real use of setting a worker into error mode
during configuration time. But this may be just me and someone else has a
real use for it.
Regards
Rüdiger
[Fwd: Re: [Fwd: [us...@httpd] Problems Compiling mod_perl and apache]]
Thoughts ? 1.3.x yuck -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. --- Begin Message --- On Mon, 2009-01-19 at 00:57 -0500, Philip M. Gollucci wrote: > email message attachment ([us...@httpd] Problems Compiling mod_perl > and apache.eml) > > Forwarded Message > > From: Ashley M. Kirchner > > Reply-To: us...@httpd.apache.org > > To: us...@httpd.apache.org > > Subject: [us...@httpd] Problems Compiling mod_perl and apache > > Date: Sun, 18 Jan 2009 17:04:23 -0700 > Please see my post to mod_perl-dev from November 29 for a fix: http://www.gossamer-threads.com/lists/modperl/dev/98573 Regards Salvador Ortiz. --- End Message ---
Bug report for Apache httpd-1.3 [2009/01/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |14518|Opn|Reg|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore | |16631|Inf|Min|2003-01-31|.htaccess errors logged outside the virtual host l| |17318|Inf|Cri|2003-02-23|Abend on deleting a temporary cache file if proxy | |19279|Inf|Min|2003-04-24|Invalid chmod options in solaris build| |21637|Inf|Nor|2003-07-16|Timeout causes a status code of 200 to be logged | |21777|Inf|Min|2003-07-21|mod_mime_magic doesn't handle little gif files| |22618|New|Maj|2003-08-21|MultiViews invalidates PATH_TRANSLATED if cgi-wrap| |25057|Inf|Maj|2003-11-27|Empty PUT access control in .htaccess overrides co| |26126|New|Nor|2004-01-14|mod_include hangs with request body | |26152|Ass|Nor|2004-01-15|Apache 1.3.29 and below directory traversal vulner| |26790|New|Maj|2004-02-09|error deleting old cache file | |29257|Opn|Nor|2004-05-27|Problem with apache-1.3.31 and mod_frontpage (dso,| |29498|New|Maj|2004-06-10|non-anonymous ftp broken in mod_proxy | |29538|Ass|Enh|2004-06-12|No facility used in ErrorLog to syslog| |30207|New|Nor|2004-07-20|Piped logs don't close read end of pipe | |30877|New|Nor|2004-08-26|htpasswd clears passwd file on Sun when /var/tmp i| |30909|New|Cri|2004-08-28|sporadic segfault resulting in broken connections | |31975|New|Nor|2004-10-29|httpd-1.3.33: buffer overflow in htpasswd if calle| |32078|New|Enh|2004-11-05|clean up some compiler warnings | |32539|New|Trv|2004-12-06|[PATCH] configure --enable-shared= brocken on SuSE| |32974|Inf|Maj|2005-01-06|Client IP not set | |33086|New|Nor|2005-01-13|unconsistency betwen 404 displayed path and server| |33495|Inf|Cri|2005-02-10|Apache crashes with "WSADuplicateSocket failed for| |33772|New|Nor|2005-02-28|inconsistency in manual and error reporting by sue| |33875|New|Enh|2005-03-07|Apache processes consuming CPU| |34108|New|Nor|2005-03-21|mod_negotiation changes mtime to mtime of Document| |34114|New|Nor|2005-03-21|Apache could interleave log entries when writing t| |34404|Inf|Blk|2005-04-11|RewriteMap prg can not handle fpout | |34571|Inf|Maj|2005-04-22|Apache 1.3.33 stops logging vhost| |34573|Inf|Maj|2005-04-22|.htaccess not working / mod_auth_mysql| |35424|New|Nor|2005-06-20|httpd disconnect in Timeout on CGI| |35439|New|Nor|2005-06-21|Problem with remove "/../" in util.c and mod_rewri| |35547|Inf|Maj|2005-06-29|Problems with libapreq 1.2 and Apache::Cookie | |3|New|Nor|2005-06-30|Can't find DBM on Debian Sarge| |36375|Opn|Nor|2005-08-26|Cannot include http_config.h from C++ file| |37166|New|Nor|2005-10-19|Under certain conditions, mod_cgi delivers an empt| |37185|New|Enh|2005-10-20|AddIcon, AddIconByType for OpenDocument format| |37252|New|Reg|2005-10-26|gen_test_char reject NLS string | |38989|New|Nor|2006-03-15|restart + piped logs stalls httpd for 24 minutes (| |39104|New|Enh|2006-03-25|[FR] fix build with -Wl,--as-needed | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |39937|New|Nor|2006-06-30|Garbage output if README.html is gzipped or compre| |40176|New|Nor|2006-08-03|magic and mime| |40224|Ver|Nor|2006-08-10|System time crashes Apache @year 2038 (win32 only?| |41279|New|Nor|2007-01-02|Apache 1.3.37 htpasswd is vulnerable to buffer ove| |42355|New|Maj|2007-05-08|Apache 1.3 permits non-rfc HTTP error code >= 600 | |43626|New|Maj|2007-10-15|r->path_info returning invalid value | |44768|
