Re: hi
Norton AntiVirus removed the attachment: document.zip. The attachment was infected with the [EMAIL PROTECTED] virus. [EMAIL PROTECTED] wrote: The message contains Unicode characters and has been sent as a binary attachment.
Re: mystery solved... perhaps.
On Mon, Jan 26, 2004 at 04:55:34PM -0600, Ben Collins-Sussman wrote: On Fri, 2004-01-23 at 08:07, Joe Orton wrote: Nice, this is easy enough to reproduce. It only fills up because the httpd children all have the read end of the pipe open, which is a bug in itself. Applying below ensures that the pipe gets closed when the piped logger exits, and so writes() fail with ETERM rather than blocking up in the leftover children. Yup, it fixes the immediate hanging-httpd problem, but then the httpd child is left unable to log *anything* after the 'graceful' for the remainder of the svn commit. If the 'graceful' happens early on, you could potentially lose all logging for most of the commit. It's not a real fix. Yeah, that naive patch also broke reviving a piped logger which dies unexpectedly, and probably more. Please do file a bug on this issue. joe
Proxy hiccups with WSAEADDRINUSE
We are using httpd 2.0.48 as a forward proxy. We run on Windows 2000 and 2003 servers and have seen weird errors when the load is high. Proxy vomits in the error log: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 1.2.3.4:80 (1.2.3.4) failed ... hundreds of megabytes of these errors. 10048 is WSAEADDRINUSE. It seems to happen in proxy_util.c in ap_proxy_connect_to_backend() when apr_connect() is called. My interpretation is that the host is out of free local ports. 'netstat' also shows a very large number of connections. Is my interpretation correct? Is there anything that can be done? Has anyone else seen this? -- Sami Tikka, senior software engineer, F-Secure Corporation tel: +358 9 2520 5115, fax: +358 9 2520 5015 http://www.F-Secure.com BE SURE.
Re: Proxy hiccups with WSAEADDRINUSE
Tikka, Sami wrote: [error] (OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : proxy: HTTP: attempt to connect to 1.2.3.4:80 (1.2.3.4) failed ... hundreds of megabytes of these errors. 10048 is WSAEADDRINUSE. It seems to happen in proxy_util.c in ap_proxy_connect_to_backend() when apr_connect() is called. My interpretation is that the host is out of free local ports. 'netstat' also shows a very large number of connections. Is my interpretation correct? Is there anything that can be done? Has anyone else seen this? your interpretation sounds correct to me see http://www.ncftpd.com/ncftpd/doc/misc/ephemeral_ports.html#Windows
Re: [PATCH] raise MAX_SERVER_LIMIT
worker MPM stack corruption in parent: int free_slots[MAX_SPAWN_RATE]; ... /* great! we prefer these, because the new process can * start more threads sooner. So prioritize this slot * by putting it ahead of any slots with active threads. * * first, make room by moving a slot that's potentially still * in use to the end of the array */ NEW CODE- ap_assert(free_length MAX_SPAWN_RATE); free_slots[free_length] = free_slots[totally_free_length]; [Tue Jan 27 12:20:19 2004] [crit] [Tue Jan 27 12:20:19 2004] file worker.c, line 1590, assertion free_length MAX_SPAWN_RATE failed
Re: [PATCH] raise MAX_SERVER_LIMIT
Jeff Trawick wrote:
worker MPM stack corruption in parent:
int free_slots[MAX_SPAWN_RATE];
...
/* great! we prefer these, because the new process can
* start more threads sooner. So prioritize this slot
* by putting it ahead of any slots with active threads.
*
* first, make room by moving a slot that's potentially
still
* in use to the end of the array
*/
NEW CODE- ap_assert(free_length MAX_SPAWN_RATE);
free_slots[free_length] =
free_slots[totally_free_length];
[Tue Jan 27 12:20:19 2004] [crit] [Tue Jan 27 12:20:19 2004] file
worker.c, line 1590, assertion free_length MAX_SPAWN_RATE failed
I'm testing with this patch currently (so far so good):
Index: server/mpm/worker/worker.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v
retrieving revision 1.145
diff -u -r1.145 worker.c
--- server/mpm/worker/worker.c 27 Jan 2004 15:19:58 - 1.145
+++ server/mpm/worker/worker.c 27 Jan 2004 19:20:10 -
@@ -1441,7 +1441,8 @@
++idle_thread_count;
}
}
-if (any_dead_threads totally_free_length idle_spawn_rate
+if (any_dead_threads totally_free_length idle_spawn_rate
+ free_length MAX_SPAWN_RATE
(!ps-pid /* no process in the slot */
|| ps-quiescing)) { /* or at least one is going away */
if (all_dead_threads) {
Re: fstat?
Brian Akins wrote: More of an apr question, Any reason there is no equivalent to fstat? Never mind. I found it. obviously it's apr_file_info_get -- Brian Akins Senior Systems Engineer CNN Internet Technologies
Re: page out of date
On 26.01.2004, at 18:32, Aryeh Katz wrote: http://apache.get-software.com/httpd/binaries/win32/README.html doesn't have the correct version numbers. Fixed (also in HEADER.html). As an aside, would it make more sense to use SSI, and get the version number from the SERVER_SOFTWARE environment variable (I assume apache.org will always be running the most up to date version of apache). Perhaps on apache.org this would be doable but keep in mind that we don't have any control over the mirrors (see your URL above!). Furthermore there's usually only one version of Apache running, 1.3 or 2.0, so how would we get to the other version number? Cheers, Erik -- Aryeh Katz SecureD Services http://www.secured-services.com/ 410 653 0700 x 2 smime.p7s Description: S/MIME cryptographic signature
Re: fstat?
On Tue, 27 Jan 2004, Brian Akins wrote: Any reason there is no equivalent to fstat? Never mind. I found it. obviously it's apr_file_info_get It used to be called apr_stat(), actually ... but then we went through a naming sterilization process so it ended up as apr_file_info_get(). :)
adding output filters in quickhandler
Possible bug: If I add an output filter in the quickhandler for something like /foo/ and later mod_dir changes it to /foo/index.html, my output filter is never ran. Is this why mod_cache cannot cache things that end in /. This just seems broken... -- Brian Akins Senior Systems Engineer CNN Internet Technologies
worker MPM parent exits
Colm MacCarthaigh wrote:
On Mon, Jan 26, 2004 at 10:05:33PM +, Colm MacCarthaigh wrote:
disable the check for geteuid()==0 and see if you get backtrace?
exception hook purposefully doesn't run as root (I assume your parent is
running as root)
No problem, first thing tomorrow :)
O.k., done that, and now have a useful backtrace (might we worth adding
a #define to turn those checks off):
yeah... note that it looks like apache-1.3 is about to get the hook
too, but it is enabled via a directive in httpd.conf
(EnableExceptionHook {on|off}).. maybe a special keyword like AllUids
could be used to enable the hook for root without rebuilding the server...
backtrace for signal 11 from process 0 (parent 7786, thread pid 7789)
main() is at 808e124
/usr/local/web/modules/mod_backtrace.so[0x550149bf]
/usr/local/web/modules/mod_backtrace.so[0x55014a34]
/usr/local/web/bin/httpd(ap_run_fatal_exception+0x30)[0x80947f8]
/usr/local/web/bin/httpd[0x8094847]
/usr/local/web/bin/httpd[0x8094880]
not enough entries in backtrace :) I guess that is a stack corruption
issue?
Attaching gdb to the running process before it dies gets me
nowhere:
Program received signal SIGSEGV, Segmentation fault.
0x0008 in ?? ()
yeah, been there done that seen that :(
I've been debugging similar problem with 2.0.47 for the last day or
so... took a while to happen upon your discussion within the innocuous
thread [PATCH] raise MAX_SERVER_LIMIT ;)
I don't have any hard data yet other than to say I see something roughly
similar under load and something is corrupted with stackframes
preventing cores or controlling parent under gdb or apparently any other
standard techniques from shedding any light on the issue. I'll be
adding some sort of tracing to find out more closely what the parent is
doing when it crashes.
Yesterday I had strace running on parent at the time and the last
syscall showed it killing a child via write(!), then SIGSEGV.
Re: [PATCH] raise MAX_SERVER_LIMIT
Colm MacCarthaigh wrote: On Mon, Jan 26, 2004 at 06:28:03PM +, Colm MacCarthaigh wrote: I'd love to find out what's causing your worker failures. Are you using any thread-unsafe modules or libraries? Not to my knowledge, I wasn't planning to do this till later, but I've bumped to 2.1, I'll try out the forensic_id and backtrace modules right now, and see how that goes. *sigh*, forensic_id didn't catch it, backtrace didn't catch it, whatkilledus didn't catch it, all tried individually. The parent just dumps core; the children live on, serve their content and log their request and then drop off one by one. No uncomplete requests, no backtrace or other exception info thrown into any log. corefile is as useful as ever, unbacktracable. suggestions welcome! mod_log_forensic? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
new core module mod_version
That has been long time on my todo (hello Stas! :-) There's a new module I'd like to add to the core distribution. It makes use of the new httpd version query function (ap_get_server_revision). It introduces IfVersion containers, where you can depend your config on a particular httpd version. I consider this as a very useful feature for test suites and big companies, which typically switch smoothly between versions. I've uploaded the module here: http://cvs.apache.org/~nd/mod_version.c. The are some more detailed descriptions at the beginning of the file after the license. What do you think? nd
