Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Mon, Sep 17, 2001 at 11:23:14AM -0700, Ryan Bloom wrote: > Forcing people to use SIGUSR1on a platform that has co-opted that signal > is broken. Obviously, that wouldn't work. My patch allowed SIGWINCH to be used on Linux 2.0 while switching the default to be SIGUSR1 on sane platforms. Your complaint is that the signal must be the same on all platforms. Therefore, I ask what you would like to do (should this be a vote?): [ ] Enforce SIGUSR1 across all platforms and drop support for any platform that does not allow SIGUSR1 to be used for graceful restart. [ ] Allow the default to be SIGUSR1, but on platforms on which SIGUSR1 is not viable, use an alternative signal (such as SIGWINCH on Linux 2.0/glibc 2.0). This would also allow the site admin to customize the signal at configure time. Since there is a veto against the use of SIGWINCH by default, the current code in CVS is broken. I would like to resolve this before we tag and roll again. -- justin
Re: [Fwd: httpd-2.0 nightly build log]
From: "Cliff Woolley" <[EMAIL PROTECTED]> Sent: Monday, September 17, 2001 10:41 PM > On Mon, 17 Sep 2001, Ian Holsman wrote: > > > mod_cgi seems to be a bit borked. > > See if my commit fixed it for you as well... it did for me. It seems to > have just been a constness problem in disguise. Entirely my fault - thanks for the fix, Cliff!
Re: New post-log-transaction hook?
From: "Jon Travis" <[EMAIL PROTECTED]> Sent: Monday, September 17, 2001 6:32 PM > I tried setting keepalive == 0 in the handler, and doing my ju-ju in > the log_transaction phase. The client was still hanging around. That sounds right ... the lazy disconnect logic in httpd can leave a connection hanging around a bit. The client will be flushed out soon enough - and httpd shouldn't be wasting any more resources/cpu slices on it. Did adding your hook at the very back end this change the lazy close time profile? Bill
Re: [Fwd: httpd-2.0 nightly build log]
On Mon, 17 Sep 2001, Ian Holsman wrote: > mod_cgi seems to be a bit borked. See if my commit fixed it for you as well... it did for me. It seems to have just been a constness problem in disguise. Thanks, --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
[Fwd: httpd-2.0 nightly build log]
mod_cgi seems to be a bit borked. Original Message Build started Mon Sep 17 19:00:00 PDT 2001 on Linux 2.4.3-12smp Checking out httpd-2.0 apr apr-util httpd-proxy httpd-test Building httpd-2.0-nightly Merging package apr Merging package apr_util Merging package httpd_proxy Merging package httpd_test Building config in httpd-2.0-nightly Configuring in httpd-2.0-nightly w/options --enable-so --enable-shared --enable-maintainer-mode --enable-auth-anon --enable-auth-dbm --enable-auth-db --enable-auth-digest --enable-file-cache --enable-echo --enable-cache --enable-mime-magic --enable-cern-meta --enable-expires --enable-headers --enable-usertrack --enable-unique-id --enable-proxy --enable-proxy-connect --enable-proxy-ftp --enable-proxy-http --enable-dav --enable-info --enable-suexec --enable-cgi --enable-cgid --enable-dav-fs --enable-vhost-alias --enable-rewrite --enable-case-filter --enable-case-filter-in -prefix=/usr/local/src/nightly/httpd-2.0-install Not configured: --enable-charset-lite --enable-disk-cache --with-tls=/usr --with-ssl=/usr --enable-ssl --enable-tls Making in httpd-2.0-nightly mod_cache.c: In function `ap_cache_in_filter': mod_cache.c:355: warning: `date' might be used uninitialized in this function mod_cgi.c: In function `include_cmd': mod_cgi.c:812: warning: passing arg 1 of pointer to function from incompatible pointer type htpasswd.o: In function `main': /usr/local/src/nightly/httpd-2.0-nightly/support/htpasswd.c:601: the use of `tmpnam' is dangerous, better use `mkstemp' htdigest.o: In function `main': /usr/local/src/nightly/httpd-2.0-nightly/support/htdigest.c:266: the use of `tmpnam' is dangerous, better use `mkstemp' Build finished Mon Sep 17 19:08:31 PDT 2001
Re: -- Apache: Not enough file descriptors --
Gunter, thank you for forwarding my message -- I really appreciate you taking the time to do this for me. I got all your messages but haven't had time to keep up because I just got notice recently from my upstream provider that my IP addresses are all changing and so lately I'm very busy with switching everything over (it's a big job for 500 internet domains). I was wondering, in the code for Apache, is there an item called "FD_SETSIZE" or some such? I remember reading somewhere that increasing this from its current setting of "64" may help solve the problem -- perhaps if you find it you can change it to 65535 or something and I can let you know if that solves the problem? Thanks once again for everything, and I'm sorry for not getting back to you earlier. > Hi all, > the following was posted in one of our Novell newsgroups; > but as Randy has found that it's not only related to NetWare platform, > I post it here... any hints or tips solving this issue are welcome > (I'm in contact with Randy and will forward to him; he's not > subscribed to the list). Guenter. > > Randolf Richardson wrote 2 Sep 2001 21:27:38 GMT: > > I've run into a scalability problem with Apache Web Server, > and have > discovered that it's not unique to the NetWare platform either -- it > seems that Solaris, FreeBSD, Linux, and other flavours of Unix have > seen this problem too. > > I've included a lot of links (below) that document "too many > open files" > bugs/errors which were reported to the Apache software foundation. In > particular, please follow the very last link in the list which > discusses compiled code not recognizing a work-around parameter. > > I believe that Apache is the problem because I've written an > NLM in the > past which opens 2,500 files and keeps them all open until the > administrator presses a key, thus proving that a single thread in > NetWare can handle this many files without a problem (and NetWare > handles it very quickly too). > > Currently, I'm still suffering with Novell's Web Server 3.1 > product, a > now discontinued HTTP server which was originally designed for NetWare > 4.11, and it's handling more than 500 internet sites, each of which > have separate ERROR and ACCESS logs, thus the web server has a MINIMUM > of more than 1,000 files open at any one time, and it's stable. In my > opinion, Novell Web Server 3.1 is still the best and most reliable web > server on the NetWare platform. Apache, on the other hand, causes the > server to freeze (cold boot is required at this point) if more than 32 > virtual hosts are configured (each host has two log files, ERROR and > ACCESS, and one Listen directive, which accounts for three file > descriptors per host, plus additional file descriptors required to > send content to browsers). > > As soon as Apache can meet my scalability needs, I will be > switching to > it, so I'm really hoping this issue can get some immediate attention. > All other aspects of Apache satisfy me, and far exceed the features > currently available in Novell Web Server 3.1. > > The links... > > Too many open files > http://bugs.apache.org/index.cgi/full/2609 > > Open files limited > http://bugs.apache.org/index.cgi/full/5503 > > Not enough file descriptors?? > http://bugs.apache.org/index.cgi/full/2430 > (Suggests reducing number of log files, but this isn't > an > acceptable or realistic solution for larger ISPs) > > Apache dies, too many open files in error log > http://bugs.apache.org/index.cgi/full/6109 > (Possibly resolved by removing JServ/Java support > before > compiling) > > Apache Server Frequently Asked Questions > http://httpd.apache.org/docs/misc/FAQ.html > (See problem described in item E.1: Why can't I run > more than > virtual hosts?) > > Too many virtual hosts cause cgi scripts to stop > working http://bugs.apache.org/index.cgi/full/1181 > > exits with "Too many open files: unable to open a file > descriptor > above 15 ..." > http://bugs.apache.org/index.cgi/full/4199 > (Suggests reducing number of log files, but this isn't > an > acceptable/realistic solution) > > Not enough file descriptors > http://bugs.apache.org/index.cgi/full/4195 > > Thanks in advance. > > -- > Randolf Richardson - [EMAIL PROTECTED] > Inter-Corporate Computer & Network Services, Inc. > Vancouver, British Columbia, Canada > http://www.8x.ca/ > Randolf Richardson - [EMAIL PROTECTED] Inter-Corporate Computer & Network Servic
problem with ap_config.h,v in repo??
I just tried to pull up this: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/ap_config.h?annotate=1.66 And got this: Python Exception Occurred Traceback (innermost last): File "/home/gstein/viewcvs/lib/viewcvs.py", line 2231, in run_cgi main() File "/home/gstein/viewcvs/lib/viewcvs.py", line 2210, in main view_annotate(request) File "/home/gstein/viewcvs/lib/viewcvs.py", line 1849, in view_annotate blame.make_html(request.cvsroot, request.where + ',v', rev) File "/home/gstein/viewcvs/lib/blame.py", line 608, in make_html revision = parser.parse_cvs_file(filename, opt_rev) File "/home/gstein/viewcvs/lib/blame.py", line 499, in parse_cvs_file raise RuntimeError, 'error: illegal RCS file' RuntimeError: error: illegal RCS file Is there really a corruption in the ,v file or is it something simple? I've never seen this message before (other files I looked at currently work fine, btw). --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: new developer
Pavel Zaitsev wrote: > Hi, > I am would like to participate in 2.0 development, Welcome, neat. > whatever I can do. Generally people work on what interests them, or you can look in the STATUS file for things what need attention. > However I wonder if there cookbook style page, on 2.0 or apache development > in general, Not that I know of, people start writing one, but bringing it to closure is hard. > where I can learn how to post patches, you post them here. The recomended ritual is to get your copy of the sources using CVS. "cvs diff -u" will generate the patch in a format approprate to submit. > peopl ... they assume that patches > work? we like to think people who submit patches test them agains current source before they submit them. But people with commit rights are careful to review them before apply them to the master copy. Be prepared for some constructive critique when you submit patches. Please feel free to ask more questions. - ben
Re: new developer
On Mon, Sep 17, 2001 at 04:34:04PM -0700, Pavel Zaitsev wrote: > Hi, > I am would like to participate in 2.0 development, whatever I can do. > However I wonder if there cookbook style page, on 2.0 or apache development > in general, where I can learn how to post patches, extract them from > my code? I see people posting patches all the time, they assume that patches > work? I am not talking about patches in particular, but conventions in place > that would make my patches be applied, that is if they are correct and work > and would not be dismissed because of my language. > thanks, > pavel Welcome. Check out: http://dev.apache.org/ More specifically: http://dev.apache.org/patches.html Hope this helps. Good luck. =-) -- justin
new developer
Hi, I am would like to participate in 2.0 development, whatever I can do. However I wonder if there cookbook style page, on 2.0 or apache development in general, where I can learn how to post patches, extract them from my code? I see people posting patches all the time, they assume that patches work? I am not talking about patches in particular, but conventions in place that would make my patches be applied, that is if they are correct and work and would not be dismissed because of my language. thanks, pavel -- Research causes cancer in rats. 110461387 http://gpg.md5.ca http://perlpimp.com
Re: New post-log-transaction hook?
I tried setting keepalive == 0 in the handler, and doing my ju-ju in the log_transaction phase. The client was still hanging around. -- Jon On Mon, Sep 17, 2001 at 04:11:58PM -0700, Ryan Bloom wrote: > On Monday 17 September 2001 03:52 pm, Jon Travis wrote: > > Why can't you do it in the log_transaction phase. Assuming this is > not a keepalive connection, the client will be gone by the time that > phase is run. If this is a keep-alive transaction, then you won't > save anything by adding another phase. > > Ryan > > > I've got a bit of code that needs to run after a connection to a client > > has been closed. Right now I can (kind of) spoof this by setting the > > keepalive for the client to 0, and registering a cleanup on the > > request_req pool. Unfortunately the code in there is somewhat bulky, > > so any subsequent cleanups that it registers will never get called > > (apparently registering a cleanup within a cleanup no workie). > > > > I'd like to propose a new hook which gets run after connection to > > the client has been closed. (in my case, I run some cleanup code > > which can take a while, and would like the client to be on its way). > > > > Any thoughts? > > > > -- Jon > > -- > > __ > Ryan Bloom[EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > --
RE: New post-log-transaction hook?
IMHO, It would also be a *hack* - it depends on what that code does.. It just doesn't seem logical for me to do something that's "not log_transaction concerned" during that phase.. -Madhu -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 4:12 PM To: [EMAIL PROTECTED]; Jon Travis Subject: Re: New post-log-transaction hook? On Monday 17 September 2001 03:52 pm, Jon Travis wrote: Why can't you do it in the log_transaction phase. Assuming this is not a keepalive connection, the client will be gone by the time that phase is run. If this is a keep-alive transaction, then you won't save anything by adding another phase. Ryan > I've got a bit of code that needs to run after a connection to a client > has been closed. Right now I can (kind of) spoof this by setting the > keepalive for the client to 0, and registering a cleanup on the > request_req pool. Unfortunately the code in there is somewhat bulky, > so any subsequent cleanups that it registers will never get called > (apparently registering a cleanup within a cleanup no workie). > > I'd like to propose a new hook which gets run after connection to > the client has been closed. (in my case, I run some cleanup code > which can take a while, and would like the client to be on its way). > > Any thoughts? > > -- Jon -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] worker MPM patch: "short-and-sweet"
On Mon, Sep 17, 2001 at 04:07:06PM -0700, Brian Pane wrote: > Aaron Bannert wrote: > > >After working with my two proposed worker MPM models, I've become more > >confident in the simple model. I'll continue benchmarking both designs, > >but I wanted to get this one out to fix what's in CVS right now, and > >so I can provide some more tweaks I've been working on (turn the LIFO > >queue to a FIFO, fix the scoreboard states, setconcurrency, etc...). > > > >Again, I've tested this patch extensively on solaris and linux with > >favorable results. > > > >Patch description: > >- Don't reuse transaction pools, instead create one for each new > > connection request. This seems to incur less overhead than trying > > to shuffle the pools around for reuse. > >- Get rid of one of the fd_queue condition variables. We don't need > > to wait on the queue if it's full, that means the caller didn't > > allocate enough entries in the queue. This relieves some overhead > > from signal/condition management. > > > Looks reasonable to me. I liked the more complicated "time-space tradeoff" > design better because it's theoretically more scalable, but if the "short > and sweet" design can outperform prefork in multiprocessor tests (e.g., > Ian's 8-CPU mstone benchmark) then I'm in favor of going with the simple > approach. I will continue to work on the more elaborate model, but for now this patch is an incremental improvement to what we have in CVS (faster, much cleaner, partial rollback to an older model). The LIFO patch is ready and waiting for this to be commited. :) -aaron
Re: New post-log-transaction hook?
On Monday 17 September 2001 03:52 pm, Jon Travis wrote: Why can't you do it in the log_transaction phase. Assuming this is not a keepalive connection, the client will be gone by the time that phase is run. If this is a keep-alive transaction, then you won't save anything by adding another phase. Ryan > I've got a bit of code that needs to run after a connection to a client > has been closed. Right now I can (kind of) spoof this by setting the > keepalive for the client to 0, and registering a cleanup on the > request_req pool. Unfortunately the code in there is somewhat bulky, > so any subsequent cleanups that it registers will never get called > (apparently registering a cleanup within a cleanup no workie). > > I'd like to propose a new hook which gets run after connection to > the client has been closed. (in my case, I run some cleanup code > which can take a while, and would like the client to be on its way). > > Any thoughts? > > -- Jon -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] worker MPM patch: "short-and-sweet"
Aaron Bannert wrote: >After working with my two proposed worker MPM models, I've become more >confident in the simple model. I'll continue benchmarking both designs, >but I wanted to get this one out to fix what's in CVS right now, and >so I can provide some more tweaks I've been working on (turn the LIFO >queue to a FIFO, fix the scoreboard states, setconcurrency, etc...). > >Again, I've tested this patch extensively on solaris and linux with >favorable results. > >Patch description: >- Don't reuse transaction pools, instead create one for each new > connection request. This seems to incur less overhead than trying > to shuffle the pools around for reuse. >- Get rid of one of the fd_queue condition variables. We don't need > to wait on the queue if it's full, that means the caller didn't > allocate enough entries in the queue. This relieves some overhead > from signal/condition management. > Looks reasonable to me. I liked the more complicated "time-space tradeoff" design better because it's theoretically more scalable, but if the "short and sweet" design can outperform prefork in multiprocessor tests (e.g., Ian's 8-CPU mstone benchmark) then I'm in favor of going with the simple approach. --Brian
Re: New post-log-transaction hook?
On Mon, Sep 17, 2001 at 07:01:21PM -0400, Cliff Woolley wrote: > On Mon, 17 Sep 2001, Jon Travis wrote: > > > I've got a bit of code that needs to run after a connection to a client > > has been closed. Right now I can (kind of) spoof this by setting the > > keepalive for the client to 0, and registering a cleanup on the > > request_req pool. Unfortunately the code in there is somewhat bulky, > > so any subsequent cleanups that it registers will never get called > > (apparently registering a cleanup within a cleanup no workie). > > > > I'd like to propose a new hook which gets run after connection to > > the client has been closed. (in my case, I run some cleanup code > > which can take a while, and would like the client to be on its way). > > Why can't you just register a cleanup on c->pool instead of r->pool? > Well, I can register a cleanup on either pool, create a new subpool and destroy it myself before I return from the cleanup. That would solve all the problems, but it does seem really hackish (and an abuse of the cleanups). -- Jon
Re: New post-log-transaction hook?
On Mon, 17 Sep 2001, Jon Travis wrote: > I've got a bit of code that needs to run after a connection to a client > has been closed. Right now I can (kind of) spoof this by setting the > keepalive for the client to 0, and registering a cleanup on the > request_req pool. Unfortunately the code in there is somewhat bulky, > so any subsequent cleanups that it registers will never get called > (apparently registering a cleanup within a cleanup no workie). > > I'd like to propose a new hook which gets run after connection to > the client has been closed. (in my case, I run some cleanup code > which can take a while, and would like the client to be on its way). Why can't you just register a cleanup on c->pool instead of r->pool? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
New post-log-transaction hook?
I've got a bit of code that needs to run after a connection to a client has been closed. Right now I can (kind of) spoof this by setting the keepalive for the client to 0, and registering a cleanup on the request_req pool. Unfortunately the code in there is somewhat bulky, so any subsequent cleanups that it registers will never get called (apparently registering a cleanup within a cleanup no workie). I'd like to propose a new hook which gets run after connection to the client has been closed. (in my case, I run some cleanup code which can take a while, and would like the client to be on its way). Any thoughts? -- Jon
Re: cvs commit: httpd-2.0/modules/generators mod_cgi.h mod_cgi.c
Hi Bill. just a little nit. Doxygen doesn't use @tip (replace with either @warning/@remark) or @deffunc (not required). On Mon, 2001-09-17 at 15:12, [EMAIL PROTECTED] wrote: > wrowe 01/09/17 15:12:50 > > Modified:modules/generators mod_cgi.c > Added: modules/generators mod_cgi.h > Log: > Here's the declaration for all to share. Don't expect many to use it. > > Revision ChangesPath > 1.105 +1 -17 httpd-2.0/modules/generators/mod_cgi.c > > Index: mod_cgi.c > === > RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgi.c,v > retrieving revision 1.104 > retrieving revision 1.105 > diff -u -r1.104 -r1.105 > --- mod_cgi.c 2001/09/17 21:07:35 1.104 > +++ mod_cgi.c 2001/09/17 22:12:49 1.105 > @@ -94,25 +94,9 @@ >#include "ap_mpm.h" >#include "mod_core.h" >#include "../filters/mod_include.h" > +#include "mod_cgi.h" > > - >module AP_MODULE_DECLARE_DATA cgi_module; > - > -/* There has to be a better place to put this - uhm... where exactly? */ > -/** > - * Reprocess the command and arguments to execute the given CGI script. > - * @param cmd Pointer to the command to execute (may be overridden) > - * @param argv Pointer to the arguments to pass (may be overridden) > - * @param r The current request > - * @param p The pool to allocate correct cmd/argv elements within. > - * @deffunc apr_status_t ap_cgi_build_command(const char **cmd, const char >***argv, request_rec *r, apr_pool_t *p) > - * @tip This callback may be registered by the os-specific module > - * to correct the command and arguments for apr_proc_create invocation > - * on a given os. mod_cgi will call the function if registered. > - */ > -APR_DECLARE_OPTIONAL_FN(apr_status_t, ap_cgi_build_command, > -(const char **cmd, const char ***argv, > - request_rec *r, apr_pool_t *p)); > >static APR_OPTIONAL_FN_TYPE(ap_register_include_handler) *cgi_pfn_reg_with_ssi; >static APR_OPTIONAL_FN_TYPE(ap_ssi_get_tag_and_value) *cgi_pfn_gtv; > > > > 1.1 httpd-2.0/modules/generators/mod_cgi.h > > Index: mod_cgi.h > === > /* >* The Apache Software License, Version 1.1 >* >* Copyright (c) 2000-2001 The Apache Software Foundation. All rights >* reserved. >* >* Redistribution and use in source and binary forms, with or without >* modification, are permitted provided that the following conditions >* are met: >* >* 1. Redistributions of source code must retain the above copyright >*notice, this list of conditions and the following disclaimer. >* >* 2. Redistributions in binary form must reproduce the above copyright >*notice, this list of conditions and the following disclaimer in >*the documentation and/or other materials provided with the >*distribution. >* >* 3. The end-user documentation included with the redistribution, >*if any, must include the following acknowledgment: >* "This product includes software developed by the >*Apache Software Foundation (http://www.apache.org/)." >*Alternately, this acknowledgment may appear in the software itself, >*if and wherever such third-party acknowledgments normally appear. >* >* 4. The names "Apache" and "Apache Software Foundation" must >*not be used to endorse or promote products derived from this >*software without prior written permission. For written >*permission, please contact [EMAIL PROTECTED] >* >* 5. Products derived from this software may not be called "Apache", >*nor may "Apache" appear in their name, without prior written >*permission of the Apache Software Foundation. >* >* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED >* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES >* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE >* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR >* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, >* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF >* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND >* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, >* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT >* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF >* SUCH DAMAGE. >* >* >* This software consists of volunt
Re: cvs commit: httpd-2.0/server core.c
>module AP_MODULE_DECLARE_DATA cgi_module; > > +/* There has to be a better place to put this - uhm... where exactly? */ > +/** > + * Reprocess the command and arguments to execute the given CGI script. > + * @param cmd Pointer to the command to execute (may be overridden) > + * @param argv Pointer to the arguments to pass (may be overridden) > + * @param r The current request > + * @param p The pool to allocate correct cmd/argv elements within. > + * @deffunc apr_status_t ap_cgi_build_command(const char **cmd, const > char ***argv, request_rec *r, apr_pool_t *p) \ > + * @tip This callback may be registered by the os-specific module > + * to correct the command and arguments for apr_proc_create invocation > + * on a given os. mod_cgi will call the function if registered. > + */ > +APR_DECLARE_OPTIONAL_FN(apr_status_t, ap_cgi_build_command, > +(const char **cmd, const char ***argv, > + request_rec *r, apr_pool_t *p)); > + I obviously haven't had time to review this yet, but I can answer the question above. The APR_DECLARE_OPTIONAL_FN has to go in a header file, so that other modules can find what it declares. Then, the doxygen docs can go into that header file. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: Doc on writing 2.0 modules
> -Original Message- > From: RCHAPACH Rochester [mailto:[EMAIL PROTECTED]] > Is there any doc anywhere on writing modules for Apache 2.0? > There is some stuff at http://httpd.apache.org/docs-2.0/developer/ Any contributions or updates to this collection are welcome. Joshua.
Doc on writing 2.0 modules
Is there any doc anywhere on writing modules for Apache 2.0? Rob Simonson [EMAIL PROTECTED]
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
My opinion is that we should support this patch (in concept, not reviewed in detail) or not support Linux 2.0 with glibc 2.0. Bill - Original Message - From: "Justin Erenkrantz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 17, 2001 1:53 PM Subject: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0 > This should resolve Roy's veto by switching back to SIGUSR1 for > graceful restarts (except on Linux 2.0 with glibc 2.0). > > As I don't think you can veto a veto (call a vote?), I don't think > his veto can be overriden. But, I do want to post this before I > commit it as it is a widespread change and I may have missed > something. We could extend this even further so that SIGHUP is > also defined as a #define, but I'm not terribly sure we want to > be that extreme. > > The docs also need to be updated, but I'm not sure the best way > to phrase that it is SIGUSR1 except on one incredibly old platform > that no one should be using threads with anyway. -- justin > > Index: CHANGES > === > RCS file: /home/cvs/httpd-2.0/CHANGES,v > retrieving revision 1.358 > diff -u -r1.358 CHANGES > --- CHANGES 2001/09/06 23:58:29 1.358 > +++ CHANGES 2001/09/17 17:28:48 > @@ -1,5 +1,8 @@ > Changes with Apache 2.0.26-dev > > + *) Switch back to SIGUSR1 for graceful restarts on all platforms that > + support it. [Justin Erenkrantz] > + >*) Rewrite find_start_sequence to use a better search algorithm > to find the start tag. [Justin Erenkrantz] > > Index: configure.in > === > RCS file: /home/cvs/httpd-2.0/configure.in,v > retrieving revision 1.179 > diff -u -r1.179 configure.in > --- configure.in 2001/09/15 11:44:55 1.179 > +++ configure.in 2001/09/17 17:28:48 > @@ -142,6 +142,8 @@ > APACHE_SUBST(SHLTCFLAGS) > APACHE_SUBST(LTCFLAGS) > > +AP_RESTART_SIGNAL=SIGUSR1 > + > case $host in >*-apple-aux3*) >APR_SETVAR(APACHE_MPM, [prefork]) > @@ -157,7 +159,11 @@ >;; >*-linux-*) >case `uname -r` in > -2.[[2-9]]* ) APR_SETVAR(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, [1]) > +2.0* ) > +AP_RESTART_SIGNAL=SIGWINCH > +;; > +2.[[2-9]]* ) > +APR_SETVAR(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, [1]) > ;; > * ) > ;; > @@ -346,6 +352,10 @@ > AC_DEFINE(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, 1, >[This platform doesn't suffer from the thundering herd problem]) > fi > + > +AC_DEFINE_UNQUOTED(AP_RESTART_SIGNAL, $AP_RESTART_SIGNAL, [Signal used to gracefully restart]) > +AC_DEFINE_UNQUOTED(AP_RESTART_SIGNAL_STRING, "$AP_RESTART_SIGNAL", [Signal used to gracefully restart (as a quoted string)]) > +AC_SUBST(AP_RESTART_SIGNAL) > > dnl check for endianness > if test "$cross_compiling" = "no"; then > Index: modules/generators/mod_cgid.c > === > RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgid.c,v > retrieving revision 1.97 > diff -u -r1.97 mod_cgid.c > --- modules/generators/mod_cgid.c 2001/08/27 20:25:42 1.97 > +++ modules/generators/mod_cgid.c 2001/09/17 17:28:53 > @@ -238,10 +238,10 @@ > case APR_OC_REASON_LOST: > /* it would be better to restart just the cgid child > * process but for now we'll gracefully restart the entire > - * server by sending SIGWINCH to ourself, the httpd parent > - * process > + * server by sending AP_RESTART_SIGNAL to ourself, the httpd > + * parent process > */ > -kill(getpid(), SIGWINCH); > +kill(getpid(), AP_RESTART_SIGNAL); > break; > case APR_OC_REASON_RESTART: > apr_proc_other_child_unregister(data); > Index: modules/mappers/mod_so.c > === > RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_so.c,v > retrieving revision 1.42 > diff -u -r1.42 mod_so.c > --- modules/mappers/mod_so.c 2001/06/07 10:38:13 1.42 > +++ modules/mappers/mod_so.c 2001/09/17 17:28:53 > @@ -59,8 +59,8 @@ > /* > * This module is used to load Apache modules at runtime. This means that the > * server functionality can be extended without recompiling and even without > - * taking the server down at all. Only a HUP or WINCH signal needs to be send > - * to the server to reload the dynamically loaded modules. > + * taking the server down at all. Only a HUP or AP_RESTART_SIGNAL signal > + * needs to be sent to the server to reload the dynamically loaded modules. > * > * To use, you'll first need to build your module as a shared library, then > * update your configuration (httpd.conf) to get the Apache core to load the > @@ -98,9 +98,9 @@ > * directive to get these log messages). > * > * If you edit the LoadModule directives while th
[PATCH] shmem.c - 3rd try
Hi,
Here's a modified patch for shmem.c - including most of Justin's
comments, except for a couple of them (Support for mmap still not enabled).
Pl. review the code and let me know your suggestions.
Thanks
-Madhu
Index: shmem.c
===
RCS file: /home/cvspublic/apr/shmem/unix/shmem.c,v
retrieving revision 1.33
diff -u -r1.33 shmem.c
--- shmem.c 2001/08/30 17:11:04 1.33
+++ shmem.c 2001/09/17 18:11:05
@@ -89,32 +89,250 @@
#include
#endif
+#define MIN_BLK_SIZE 256
+
+typedef apr_int32_t index_t;
+typedef struct memoffsets_t {
+index_tl_total;/* Index to start of Free list elements */
+index_tc_used; /* Index to start of the used chunk list */
+index_tc_free; /* Index to start of the freed chunk list */
+apr_off_t shm_offset; /* The current offset of the shared memory */
+apr_size_t shm_length; /* Total length of shared memory available */
+} memoffsets_t;
+
+typedef struct memchunk_t {
+apr_off_t offset; /* Offset of the memory - from m->mem */
+apr_size_t size; /* Size of the chunk */
+index_tnext; /* Index of Next chunk in the list */
+index_tprev; /* Index of Previous chunk in the list*/
+} memchunk_t;
+
struct shmem_t {
-void *mem;
-void *curmem;
+apr_pool_t *p;
+void *mem; /* Starting address of the shared memory */
+memoffsets_t *offsets; /* Begining of the set of offsets */
+memchunk_t *list; /* Begining of the list elements */
apr_size_t length;
apr_lock_t *lock;
char *filename;
#if APR_USE_SHMEM_MMAP_TMP || APR_USE_SHMEM_MMAP_SHM || APR_USE_SHMEM_MMAP_ZERO
apr_file_t *file;
-#elif APR_USE_SHMEM_MMAP_ANON
-/* Nothing else. */
#elif APR_USE_SHMEM_SHMGET
apr_os_file_t file;
+apr_os_file_t listfd;
#elif APR_USE_SHMEM_BEOS
area_id areaid;
#endif
};
+#define SHM_ADDR(m,offset)((offset < 0) ? (void *)NULL : \
+(void *)((unsigned char *)m->mem + offset))
+
+#define LIST_INDEX(m,ptr) ((ptr == NULL) ? -1 : \
+(((unsigned char *)ptr - (unsigned char *)m->list)/sizeof(memchunk_t)))
+
+#define MAX_LIST_ELEM(m) ((m->length / MIN_BLK_SIZE) + 1)
+
+#define ROUND_UP(size) ((size < MIN_BLK_SIZE) ? MIN_BLK_SIZE : \
+((1 + ((size - 1) / sizeof (void *))) * sizeof (void *)))
+
+static index_t posn_in_sorted_list(apr_shmem_t *m, index_t *first, index_t elem)
+{
+index_t idx = *first;
+
+if (idx < 0) return -1;
+
+do {
+if (m->list[idx].offset > m->list[elem].offset)
+break;
+idx = m->list[idx].next;
+} while ((idx >= 0) && (idx < MAX_LIST_ELEM(m)) && (idx != *first));
+return idx;
+}
+
+static void add_list (apr_shmem_t *m, index_t *first, index_t elem)
+{
+index_t prev, idx;
+
+if (*first == m->offsets->c_free)
+idx = posn_in_sorted_list(m, first, elem);
+else
+idx = *first;
+
+if (idx == -1) {
+idx = *first = elem;
+prev = elem;
+}
+else
+prev = m->list[idx].prev;
+
+m->list[idx].prev = elem;
+m->list[prev].next = elem;
+m->list[elem].prev = prev;
+m->list[elem].next = idx;
+
+if (idx == m->offsets->c_free)
+*first = elem;
+}
+
+static void remove_list(apr_shmem_t *m, index_t *first, index_t elem)
+{
+index_t prev, next;
+
+next = m->list[elem].next;
+prev = m->list[elem].prev;
+m->list[prev].next = next;
+m->list[next].prev = prev;
+if (next == elem)
+*first = -1;
+}
+
+static void free_list(apr_shmem_t *m, index_t elem)
+{
+index_t idx = elem;
+if (elem >= 0) {
+idx = m->offsets->l_total - 1;
+memcpy (&(m->list[elem]), &(m->list[idx]), sizeof(memchunk_t));
+m->list[m->list[idx].prev].next = idx;
+m->list[m->list[idx].next].prev = idx;
+m->offsets->l_total--;
+}
+}
+
+static int split_chunk(apr_shmem_t *m, index_t elem, apr_size_t size)
+{
+index_t nelem = m->offsets->l_total;
+if (nelem > MAX_LIST_ELEM(m))
+return -1;
+
+m->list[nelem].size = m->list[elem].size - size;
+m->list[elem].size= size;
+m->list[nelem].offset = m->list[elem].offset + m->list[elem].size;
+add_list(m, &(m->offsets->c_free), nelem);
+m->offsets->l_total++;
+
+return nelem;
+}
+
+static index_t find_chunk_by_addr(apr_shmem_t *m, index_t first, void *addr)
+{
+index_t idx = first;
+
+if (idx < 0) return NULL;
+
+do {
+ if (SHM_ADDR(m,m->list[idx].offset) == addr)
+return idx;
+} while ((idx >= 0) && ((idx = m->list[idx].next) != first));
+
+return NULL;
+}
+
+static index_t find_chunk_by_size(apr_shmem_t *m, index_t first,apr_size_t size)
+{
+memchunk_t *iter;
+apr_size_t diff = -1;
+index_t idx = first, found = -1;
+
+if (idx < 0) return -1;
+
+do {
+if (m->list[idx].size == size)
+return id
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Monday 17 September 2001 11:15 am, Justin Erenkrantz wrote: > On Mon, Sep 17, 2001 at 11:07:13AM -0700, Ryan Bloom wrote: > > On Monday 17 September 2001 11:04 am, Justin Erenkrantz wrote: > > > > I know what the mails were about. I am simply stating that it is still > > completely bogus. > > I disagree. > > It should be SIGUSR1 everywhere. As a compromise, I allowed configure > to use SIGWINCH on Linux 2.0. Would it make more sense to give a fatal > error on that platform? -- justin Have you ever tried running a threaded app that uses SIGUSR1 on Linux 2.0? It doesn't even start. If you turn that into a fatal error, then you should be prepared to answer all of the questions from Linux users about it. If you really think that you won't get any, take a look at what happened when we forced Windows users to use WinSock2. Forcing people to use SIGUSR1on a platform that has co-opted that signal is broken. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Mon, Sep 17, 2001 at 02:01:40PM -0400, Rodent of Unusual Size wrote: > > As I don't think you can veto a veto (call a vote?), I don't think > > his veto can be overriden. > > Nope; he has to be convinced to retract it. :-) Maybe we should wait until he can speak for himself. -aaron
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Mon, Sep 17, 2001 at 11:07:13AM -0700, Ryan Bloom wrote: > On Monday 17 September 2001 11:04 am, Justin Erenkrantz wrote: > > I know what the mails were about. I am simply stating that it is still completely > bogus. I disagree. It should be SIGUSR1 everywhere. As a compromise, I allowed configure to use SIGWINCH on Linux 2.0. Would it make more sense to give a fatal error on that platform? -- justin
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
Ryan Bloom wrote: > > This is completely BOGUS! If I have a farm of web servers > running on different platforms, all of the signals should > be the same. Oh, bah. 'Windows.' 'VMS.' 'MacOS' (not OS X). I agree with Sander that the thing that should be the same is the supported commands to manipulate the server. The details of implementation have no need of being identical. Although it *is* a nice-to-have', I don't think it is anything more than that -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
[PATCH] worker MPM patch: "short-and-sweet"
After working with my two proposed worker MPM models, I've become more
confident in the simple model. I'll continue benchmarking both designs,
but I wanted to get this one out to fix what's in CVS right now, and
so I can provide some more tweaks I've been working on (turn the LIFO
queue to a FIFO, fix the scoreboard states, setconcurrency, etc...).
Again, I've tested this patch extensively on solaris and linux with
favorable results.
Patch description:
- Don't reuse transaction pools, instead create one for each new
connection request. This seems to incur less overhead than trying
to shuffle the pools around for reuse.
- Get rid of one of the fd_queue condition variables. We don't need
to wait on the queue if it's full, that means the caller didn't
allocate enough entries in the queue. This relieves some overhead
from signal/condition management.
-aaron
Index: server/mpm/worker/worker.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/worker/worker.c,v
retrieving revision 1.21
diff -u -r1.21 worker.c
--- server/mpm/worker/worker.c 2001/08/30 20:50:06 1.21
+++ server/mpm/worker/worker.c 2001/09/17 02:46:01
@@ -123,7 +123,6 @@
static int num_listensocks = 0;
static apr_socket_t **listensocks;
static fd_queue_t *worker_queue;
-static fd_queue_t *pool_queue; /* a resource pool of context pools */
/* The structure used to pass unique initialization info to each thread */
typedef struct {
@@ -204,7 +203,6 @@
/* XXX: This will happen naturally on a graceful, and we don't care otherwise.
ap_queue_signal_all_wakeup(worker_queue); */
ap_queue_interrupt_all(worker_queue);
-ap_queue_interrupt_all(pool_queue);
}
AP_DECLARE(apr_status_t) ap_mpm_query(int query_code, int *result)
@@ -558,7 +556,6 @@
int thread_slot = ti->tid;
apr_pool_t *tpool = apr_thread_pool_get(thd);
apr_socket_t *csd = NULL;
-apr_socket_t *dummycsd = NULL;
apr_pool_t *ptrans;/* Pool for per-transaction stuff */
apr_socket_t *sd = NULL;
int n;
@@ -644,20 +641,9 @@
}
got_fd:
if (!workers_may_exit) {
+/* create a new transaction pool for each accepted socket */
+apr_pool_create(&ptrans, tpool);
-/* pull the next available transaction pool from the queue */
-if ((rv = ap_queue_pop(pool_queue, &dummycsd, &ptrans))
-!= FD_QUEUE_SUCCESS) {
-if (rv == FD_QUEUE_EINTR) {
-goto got_fd;
-}
-else { /* got some error in the queue */
-csd = NULL;
-ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf,
-"ap_queue_pop");
-}
-}
-
if ((rv = apr_accept(&csd, sd, ptrans)) != APR_SUCCESS) {
csd = NULL;
ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf,
@@ -692,7 +678,9 @@
ap_scoreboard_image->parent[process_slot].quiescing = 1;
kill(ap_my_pid, SIGTERM);
+/* Unsure if this can be safely uncommented. -aaron
apr_thread_exit(thd, APR_SUCCESS);
+*/
return NULL;
}
@@ -718,12 +706,7 @@
}
process_socket(ptrans, csd, process_slot, thread_slot);
requests_this_child--; /* FIXME: should be synchronized - aaron */
-
-/* get this transaction pool ready for the next request */
-apr_pool_clear(ptrans);
-/* don't bother checking if we were interrupted in ap_queue_push,
- * because we're going to check workers_may_exit right now anyway. */
-ap_queue_push(pool_queue, NULL, ptrans);
+apr_pool_destroy(ptrans);
}
ap_update_child_status(process_slot, thread_slot,
@@ -758,23 +741,11 @@
int i = 0;
int threads_created = 0;
apr_thread_t *listener;
-apr_pool_t *ptrans;
-apr_socket_t *dummycsd = NULL;
/* We must create the fd queues before we start up the listener
* and worker threads. */
-worker_queue = apr_pcalloc(pchild, sizeof(fd_queue_t));
+worker_queue = apr_pcalloc(pchild, sizeof(*worker_queue));
ap_queue_init(worker_queue, ap_threads_per_child, pchild);
-
-/* create the resource pool of available transaction pools */
-pool_queue = apr_pcalloc(pchild, sizeof(fd_queue_t));
-ap_queue_init(pool_queue, ap_threads_per_child, pchild);
-/* fill the pool_queue with real pools */
-for (i = 0; i < ap_threads_per_child; i++) {
-ptrans = NULL;
-apr_pool_create(&ptrans, pchild);
-ap_queue_push(pool_queue, dummycsd, ptrans);
-}
my_info = (proc_info *)malloc(sizeof(proc_info));
my_info->pid = my_child_num;
Index: server/mpm/worker/fdqueue.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/worker/fdqueue.c,v
retrieving revision 1.5
diff -u -r1.5 fdqueue.c
--- serv
RE: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
> -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: 17 September 2001 19:58 > On Monday 17 September 2001 10:53 am, Justin Erenkrantz wrote: > > This is completely BOGUS! If I have a farm of web servers running > on different > platforms, all of the signals should be the same. Can't we settle for 'the command on each machine to restart, stop, etc. should be the same'? Ie. $ apachectl restart $ apachectl stop etc. The alternatives are: 1) drop support linux kernel 2.0 with glibc 2.0 2) stick with SIGWINCH (which doesn't exist on some platform(s) IIRC). Just my $0.02, Sander > Ryan > > > This should resolve Roy's veto by switching back to SIGUSR1 for > > graceful restarts (except on Linux 2.0 with glibc 2.0). > > > > As I don't think you can veto a veto (call a vote?), I don't think > > his veto can be overriden. But, I do want to post this before I > > commit it as it is a widespread change and I may have missed > > something. We could extend this even further so that SIGHUP is > > also defined as a #define, but I'm not terribly sure we want to > > be that extreme. > > > > The docs also need to be updated, but I'm not sure the best way > > to phrase that it is SIGUSR1 except on one incredibly old platform > > that no one should be using threads with anyway. -- justin > > __ > Ryan Bloom[EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -- > > >
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Monday 17 September 2001 11:04 am, Justin Erenkrantz wrote: I know what the mails were about. I am simply stating that it is still completely bogus. Ryan > On Mon, Sep 17, 2001 at 10:57:32AM -0700, Ryan Bloom wrote: > > This is completely BOGUS! If I have a farm of web servers running on > > different platforms, all of the signals should be the same. > > Roy's -1 on SIGWINCH: > > http://www.apachelabs.org/apache-mbox/200108.mbox/%3c20010830132250.A1832@w >aka.ebuilt.net%3e > > Roy's comment on making it configurable: > > http://www.apachelabs.org/apache-mbox/200108.mbox/%3c20010830154010.B2142@w >aka.ebuilt.net%3e > > -- justin > > P.S. He called it AP_SIG_GRACEFUL which is probably better than what I > had. -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Mon, Sep 17, 2001 at 10:57:32AM -0700, Ryan Bloom wrote: > This is completely BOGUS! If I have a farm of web servers running on different > platforms, all of the signals should be the same. Roy's -1 on SIGWINCH: http:[EMAIL PROTECTED]%3e Roy's comment on making it configurable: http:[EMAIL PROTECTED]%3e -- justin P.S. He called it AP_SIG_GRACEFUL which is probably better than what I had.
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
Justin Erenkrantz wrote: > > This should resolve Roy's veto by switching back to SIGUSR1 for > graceful restarts (except on Linux 2.0 with glibc 2.0). > > As I don't think you can veto a veto (call a vote?), I don't think > his veto can be overriden. Nope; he has to be convinced to retract it. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
Re: [PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
On Monday 17 September 2001 10:53 am, Justin Erenkrantz wrote: This is completely BOGUS! If I have a farm of web servers running on different platforms, all of the signals should be the same. Ryan > This should resolve Roy's veto by switching back to SIGUSR1 for > graceful restarts (except on Linux 2.0 with glibc 2.0). > > As I don't think you can veto a veto (call a vote?), I don't think > his veto can be overriden. But, I do want to post this before I > commit it as it is a widespread change and I may have missed > something. We could extend this even further so that SIGHUP is > also defined as a #define, but I'm not terribly sure we want to > be that extreme. > > The docs also need to be updated, but I'm not sure the best way > to phrase that it is SIGUSR1 except on one incredibly old platform > that no one should be using threads with anyway. -- justin __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
[PATCH] Switch back to SIGUSR1 and use SIGWINCH on Linux 2.0
This should resolve Roy's veto by switching back to SIGUSR1 for graceful restarts (except on Linux 2.0 with glibc 2.0). As I don't think you can veto a veto (call a vote?), I don't think his veto can be overriden. But, I do want to post this before I commit it as it is a widespread change and I may have missed something. We could extend this even further so that SIGHUP is also defined as a #define, but I'm not terribly sure we want to be that extreme. The docs also need to be updated, but I'm not sure the best way to phrase that it is SIGUSR1 except on one incredibly old platform that no one should be using threads with anyway. -- justin Index: CHANGES === RCS file: /home/cvs/httpd-2.0/CHANGES,v retrieving revision 1.358 diff -u -r1.358 CHANGES --- CHANGES 2001/09/06 23:58:29 1.358 +++ CHANGES 2001/09/17 17:28:48 @@ -1,5 +1,8 @@ Changes with Apache 2.0.26-dev + *) Switch back to SIGUSR1 for graceful restarts on all platforms that + support it. [Justin Erenkrantz] + *) Rewrite find_start_sequence to use a better search algorithm to find the start tag. [Justin Erenkrantz] Index: configure.in === RCS file: /home/cvs/httpd-2.0/configure.in,v retrieving revision 1.179 diff -u -r1.179 configure.in --- configure.in2001/09/15 11:44:55 1.179 +++ configure.in2001/09/17 17:28:48 @@ -142,6 +142,8 @@ APACHE_SUBST(SHLTCFLAGS) APACHE_SUBST(LTCFLAGS) +AP_RESTART_SIGNAL=SIGUSR1 + case $host in *-apple-aux3*) APR_SETVAR(APACHE_MPM, [prefork]) @@ -157,7 +159,11 @@ ;; *-linux-*) case `uname -r` in -2.[[2-9]]* ) APR_SETVAR(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, [1]) +2.0* ) +AP_RESTART_SIGNAL=SIGWINCH +;; +2.[[2-9]]* ) +APR_SETVAR(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, [1]) ;; * ) ;; @@ -346,6 +352,10 @@ AC_DEFINE(SINGLE_LISTEN_UNSERIALIZED_ACCEPT, 1, [This platform doesn't suffer from the thundering herd problem]) fi + +AC_DEFINE_UNQUOTED(AP_RESTART_SIGNAL, $AP_RESTART_SIGNAL, [Signal used to gracefully +restart]) +AC_DEFINE_UNQUOTED(AP_RESTART_SIGNAL_STRING, "$AP_RESTART_SIGNAL", [Signal used to +gracefully restart (as a quoted string)]) +AC_SUBST(AP_RESTART_SIGNAL) dnl check for endianness if test "$cross_compiling" = "no"; then Index: modules/generators/mod_cgid.c === RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgid.c,v retrieving revision 1.97 diff -u -r1.97 mod_cgid.c --- modules/generators/mod_cgid.c 2001/08/27 20:25:42 1.97 +++ modules/generators/mod_cgid.c 2001/09/17 17:28:53 @@ -238,10 +238,10 @@ case APR_OC_REASON_LOST: /* it would be better to restart just the cgid child * process but for now we'll gracefully restart the entire - * server by sending SIGWINCH to ourself, the httpd parent - * process + * server by sending AP_RESTART_SIGNAL to ourself, the httpd + * parent process */ -kill(getpid(), SIGWINCH); +kill(getpid(), AP_RESTART_SIGNAL); break; case APR_OC_REASON_RESTART: apr_proc_other_child_unregister(data); Index: modules/mappers/mod_so.c === RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_so.c,v retrieving revision 1.42 diff -u -r1.42 mod_so.c --- modules/mappers/mod_so.c2001/06/07 10:38:13 1.42 +++ modules/mappers/mod_so.c2001/09/17 17:28:53 @@ -59,8 +59,8 @@ /* * This module is used to load Apache modules at runtime. This means that the * server functionality can be extended without recompiling and even without - * taking the server down at all. Only a HUP or WINCH signal needs to be send - * to the server to reload the dynamically loaded modules. + * taking the server down at all. Only a HUP or AP_RESTART_SIGNAL signal + * needs to be sent to the server to reload the dynamically loaded modules. * * To use, you'll first need to build your module as a shared library, then * update your configuration (httpd.conf) to get the Apache core to load the @@ -98,9 +98,9 @@ * directive to get these log messages). * * If you edit the LoadModule directives while the server is live you can get - * Apache to re-load the modules by sending it a HUP or WINCH signal as normal. - * You can use this to dynamically change the capability of your server - * without bringing it down. + * Apache to re-load the modules by sending it a HUP or AP_RESTART_SIGNAL + * signal as normal. You can use this to dynamically change the capability + * of your server without bringing it down. * * Because currently there is only limited builtin support in the Config
Re: WWW-Authenticate: Negotiate
Did not someone make a patch for this early after the feature was in IE 4?
Dw
On Mon, 17 Sep 2001, Martin Kraemer wrote:
> I just noticed a feature of IIS 5.0 which is (if I am correct)
> impossible to do with Apache (1.3/2.0), albeit very useful. It
> is the the possibility to use multiple authentication schemes
> in parallel, with the client selecting the most appropriate
> version.
>
> Without much explanation, here's a response header of IIS5 for a
> request requiring authentication:
>
> HTTP/1.1 401 Unauthorized
> Server: Microsoft-IIS/5.0
> Date: Mon, 17 Sep 2001 14:01:05 GMT
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> WWW-Authenticate: Basic realm="my.fsc.net"
> Set-Cookie: RQFW={CC8D82ED-2EC6-446D-8013-68DA01CFE353}; path=/;
> Cache-Control: private
> Content-Type: text/html; charset=utf-8
> Content-Length: 1509
>
> For Apache, the alternatives "Basic" and "Digest" would be more appropriate,
> of course. But AFAICS Apache does not allow for accepting multiple
> schemes alternatively.
>
> In RFC2617, I find a reference of multiple WWW-Authenticate headers:
>
> > 4.6 Weakness Created by Multiple Authentication Schemes
> >
> > An HTTP/1.1 server may return multiple challenges with a 401 (Authenticate)
>response, and each challenge may use a different auth-scheme. A user agent MUST
>choose to use the
> > strongest auth- scheme it understands and request credentials from the user
>based upon that challenge.
> >
> > Note that many browsers will only recognize Basic and will require that it be
>the first auth-scheme presented. Servers should only include Basic if it is minimally
>acceptable.
> >
> > When the server offers choices of authentication schemes using the
>WWW-Authenticate header, the strength of the resulting authentication is only as good
>as that of the of the
> > weakest of the authentication schemes. See section 4.8 below for discussion
>of particular attack scenarios that exploit multiple authentication schemes.
>
> Now my question is:
>
> * is this feature standardized? (The first "WWW-Authenticate: Negotiate"
> looks fishy to me)
>
> * how could Apache be configured to support multiple auth schemes for
> a given resource in parallel? Currently, "AuthType Digest" allows
> only one argument, and using it multiple times just replaces the
> current setting.
>
> Martin
>
borken file permissions on daedalus (fwd)
-- 2nd Fwd message -- Subject: RE: Output from "cron" command Date: Fri, 14 Sep 2001 08:37:07 +1000 From: Andrew Kenna <[EMAIL PROTECTED]> To: "'Jose Manuel Macias Luna'" <[EMAIL PROTECTED]> please forward these responses into [EMAIL PROTECTED] as if you email this list it only gets to 3 people, none of which can fix the errors you are getting. miror-submit is only for people who want to become an apache mirror, not someone who is having problems mirroring the apache server. Andrew Apache Mirror Team -Original Message- From: Jose Manuel Macias Luna [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 7:11 PM To: [EMAIL PROTECTED] Subject: Fwd: Output from "cron" command Hello, we are having problems to make our mirror of apache, below is the rsync log. I laso have to inform you that our apache mirror is available through: ftp://ftp.rediris.es/mirror/apache and also http://apache.rediris.es This is a thttpd server, not an Apache, but if you want to link it you are welcome. We use apache in many of our servers but we chose thttpd for our mirroring service. -- Original Fwd message -- Subject: Output from "cron" command Date: Thu, 13 Sep 2001 00:40:07 +0200 (CEST) [...] Your "cron" job on zeppo [...]/rsync.apache produced the following output: receiving file list ... done send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.1-rs6000-ibm-aix3.2.README: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.1-rs6000-ibm-aix3.2.tar.gz: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.1-rs6000-ibm-aix3.2.tar.gz.md5: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.12-002257794C00-ibm-aix4.2.README: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.12-002257794C00-ibm-aix4.2.tar.gz: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.12-002257794C00-ibm-aix4.2.tar_gz.asc : Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.6-rs6000-ibm-aix4.2.README: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.6-rs6000-ibm-aix4.2.tar.gz: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.9-002257794C00-ibm-aix4.2.README: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.9-002257794C00-ibm-aix4.2.tar.gz: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.9-002257794C00-ibm-aix4.2.tar_gz.asc: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.9-0035558C4C00-ibm-aix4.3.README: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.9-0035558C4C00-ibm-aix4.3.tar.gz: Permission denied send_files failed to open dist/httpd/binaries/aix/old/apache_1.3.9-0035558C4C00-ibm-aix4.3.tar_gz.asc: Permission denied mail/apache-bugdb/200109 mail/apache-docs/200109 mail/modproxy-dev/200109 mail/apache-bugdb/ mail/apache-docs/ mail/modproxy-dev/ wrote 6039 bytes read 62795 bytes 9177.87 bytes/sec total size is 532147829 speedup is 7730.89 --- Thanks in advance, José Manuel. -- Sistemas de Informacion - webmaster, ftpmaster Centro de Comunicaciones CSIC/RedIris Spanish Academic Network for Research and Development Madrid (Spain) Tlf 91.585.51.50
Re: Fw: Regarding lower-case HTML tags
On Wed, Sep 05, 2001 at 09:19:27AM -0400, Greg Marr wrote: > > The reason it does that is that XML is case-sensitive for tag names, > and the HTML working group chose to use lowercase for XHTML. Thus, > if the pages were ever to be marked as XHTML, they'd need to be > lowercase. The XHTML reasoning is that in most cases, the text between tags consists of more lowercase text than uppercase text, and thus the overall document will compress better when sent thru mod_gz (ducks ;-) Because more text will be "equal" (i.e., share common sub-strings), the compression ration will improve. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
-- Apache: Not enough file descriptors --
Hi all, the following was posted in one of our Novell newsgroups; but as Randy has found that it's not only related to NetWare platform, I post it here... any hints or tips solving this issue are welcome (I'm in contact with Randy and will forward to him; he's not subscribed to the list). Guenter. Randolf Richardson wrote 2 Sep 2001 21:27:38 GMT: I've run into a scalability problem with Apache Web Server, and have discovered that it's not unique to the NetWare platform either -- it seems that Solaris, FreeBSD, Linux, and other flavours of Unix have seen this problem too. I've included a lot of links (below) that document "too many open files" bugs/errors which were reported to the Apache software foundation. In particular, please follow the very last link in the list which discusses compiled code not recognizing a work-around parameter. I believe that Apache is the problem because I've written an NLM in the past which opens 2,500 files and keeps them all open until the administrator presses a key, thus proving that a single thread in NetWare can handle this many files without a problem (and NetWare handles it very quickly too). Currently, I'm still suffering with Novell's Web Server 3.1 product, a now discontinued HTTP server which was originally designed for NetWare 4.11, and it's handling more than 500 internet sites, each of which have separate ERROR and ACCESS logs, thus the web server has a MINIMUM of more than 1,000 files open at any one time, and it's stable. In my opinion, Novell Web Server 3.1 is still the best and most reliable web server on the NetWare platform. Apache, on the other hand, causes the server to freeze (cold boot is required at this point) if more than 32 virtual hosts are configured (each host has two log files, ERROR and ACCESS, and one Listen directive, which accounts for three file descriptors per host, plus additional file descriptors required to send content to browsers). As soon as Apache can meet my scalability needs, I will be switching to it, so I'm really hoping this issue can get some immediate attention. All other aspects of Apache satisfy me, and far exceed the features currently available in Novell Web Server 3.1. The links... Too many open files http://bugs.apache.org/index.cgi/full/2609 Open files limited http://bugs.apache.org/index.cgi/full/5503 Not enough file descriptors?? http://bugs.apache.org/index.cgi/full/2430 (Suggests reducing number of log files, but this isn't an acceptable or realistic solution for larger ISPs) Apache dies, too many open files in error log http://bugs.apache.org/index.cgi/full/6109 (Possibly resolved by removing JServ/Java support before compiling) Apache Server Frequently Asked Questions http://httpd.apache.org/docs/misc/FAQ.html (See problem described in item E.1: Why can't I run more than virtual hosts?) Too many virtual hosts cause cgi scripts to stop working http://bugs.apache.org/index.cgi/full/1181 exits with "Too many open files: unable to open a file descriptor above 15 ..." http://bugs.apache.org/index.cgi/full/4199 (Suggests reducing number of log files, but this isn't an acceptable/realistic solution) Not enough file descriptors http://bugs.apache.org/index.cgi/full/4195 Thanks in advance. -- Randolf Richardson - [EMAIL PROTECTED] Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.8x.ca/
Re: cvs co apache-1.3
On Sun, Sep 16, 2001 at 07:16:59PM +0100, Pier Fumagalli wrote: > > To check out the htdocs directory, this is what I do: > > # cvs co apache-1.3 > > cvs server: existing repository /home/cvs/apache-1.3/htdocs does not match. > > # rm -f apache-1.3/htdocs > # cvs co httpd-docs-1.3/htdocs > ... > # mv httpd-docs-1.3/htdocs apache-1.3/htdocs > # rm -rf httpd-docs-1.3 > # cd apache-1.3 > # cvs update -APd > # Or even simpler: # echo >>~/.cvsrc update -Pd # echo >>~/.cvsrc checkout -P # cvs co apache-1.3 cvs server: existing repository /home/cvs/apache-1.3/htdocs does not match. # cd apache-1.3 # rm -fr htdocs # cvs co -d htdocs httpd-docs-1.3/htdocs Not that it matters any longer, now that the Alias has been fixed. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: WWW-Authenticate: Negotiate
Martin Kraemer wrote: > > I just noticed a feature of IIS 5.0 which is (if I am correct) > impossible to do with Apache (1.3/2.0), albeit very useful. It > is the the possibility to use multiple authentication schemes > in parallel, with the client selecting the most appropriate > version. Someone submitted a patch, or at least a discussion of the subject, to new-httpd about two years ago ISTR. I would like to see the capability in the server, since it will help digest deploy (as well as being more secure). -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
WWW-Authenticate: Negotiate
I just noticed a feature of IIS 5.0 which is (if I am correct)
impossible to do with Apache (1.3/2.0), albeit very useful. It
is the the possibility to use multiple authentication schemes
in parallel, with the client selecting the most appropriate
version.
Without much explanation, here's a response header of IIS5 for a
request requiring authentication:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/5.0
Date: Mon, 17 Sep 2001 14:01:05 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="my.fsc.net"
Set-Cookie: RQFW={CC8D82ED-2EC6-446D-8013-68DA01CFE353}; path=/;
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 1509
For Apache, the alternatives "Basic" and "Digest" would be more appropriate,
of course. But AFAICS Apache does not allow for accepting multiple
schemes alternatively.
In RFC2617, I find a reference of multiple WWW-Authenticate headers:
> 4.6 Weakness Created by Multiple Authentication Schemes
>
> An HTTP/1.1 server may return multiple challenges with a 401 (Authenticate)
>response, and each challenge may use a different auth-scheme. A user agent MUST
>choose to use the
> strongest auth- scheme it understands and request credentials from the user
>based upon that challenge.
>
> Note that many browsers will only recognize Basic and will require that it be
>the first auth-scheme presented. Servers should only include Basic if it is minimally
>acceptable.
>
> When the server offers choices of authentication schemes using the
>WWW-Authenticate header, the strength of the resulting authentication is only as good
>as that of the of the
> weakest of the authentication schemes. See section 4.8 below for discussion of
>particular attack scenarios that exploit multiple authentication schemes.
Now my question is:
* is this feature standardized? (The first "WWW-Authenticate: Negotiate"
looks fishy to me)
* how could Apache be configured to support multiple auth schemes for
a given resource in parallel? Currently, "AuthType Digest" allows
only one argument, and using it multiple times just replaces the
current setting.
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: cvs commit: httpd-2.0 STATUS
This is an ugly bug. * open a connection to apache. toss in 100 GET requests. no problem. * try the same, but with "hello" in the body of the GET request. Apache closes the connection after sending back the first response. Of course, substitute your favorite POST, PUT, PROPFIND, or whatever other method that contains a body. Bam! Apache is gonna close the connection. "wtf?" you say... Well, I tracked it down to a problem with the HTTP_IN filter and its call to apr_brigade_split() on line 690. The new, returned brigade is created in the same pool as "b" -- that pool is the request pool. Thus, at the end of the request ctx->b is cleared out, and on the next entry to the HTTP_IN filter (read_request_line for the next request), it tries to refill ctx->b with data. CORE_IN punts with APR_EOF, so the request logic thinks "done. let's shut down." There are a few band-aid solutions to the problem: 1) ctx->b->p = f->c->pool (and somehow tweak the cleanups) 2) copy the returned brigade into a properly-allocated brigade 3) pass a pool to apr_brigade_split() for the new brigade IMO, the right answer is to fix up the input processing so we don't even have to do all of that splitting and brigade munging. (otherwise, (3) is the better of the above options) Cheers, -g On Mon, Sep 17, 2001 at 11:22:53AM -, [EMAIL PROTECTED] wrote: > gstein 01/09/17 04:22:53 > > Modified:.STATUS > Log: > Found the persistent connection problem I've been observing. Nasty result of > the problems in the input filter stack. Time to rejigger, per the > discussions we've had. > > Revision ChangesPath > 1.296 +24 -1 httpd-2.0/STATUS > > Index: STATUS > === > RCS file: /home/cvs/httpd-2.0/STATUS,v > retrieving revision 1.295 > retrieving revision 1.296 > diff -u -r1.295 -r1.296 > --- STATUS 2001/09/17 02:33:40 1.295 > +++ STATUS 2001/09/17 11:22:52 1.296 > @@ -1,5 +1,5 @@ >APACHE 2.0 STATUS: -*-text-*- > -Last modified at [$Date: 2001/09/17 02:33:40 $] > +Last modified at [$Date: 2001/09/17 11:22:52 $] > >Release: > > @@ -107,6 +107,29 @@ > >This builds mod_headers as a DSO (good) but builds mod_mime >as a compiled-in module (bad). > + > +* revamp the input filter semantics, per discussions since > + February (and especially at the hackathon last > + April). Specifically, ap_get_brigade will return a brigade with > + *up to* a specific number of bytes, or a "line" of data. The > + read may be blocking or nonblocking. ap_getline() will be > + refactored into apr_brigade_getline(), and then DECHUNK can use > + f->next (ap_getline will always read "top of input stack"). Also > + fix the bug where request body content will end up closing the > + connection (buggering up persistent conns). > + > + - socket bucket and core input filter changes. see end of > +message ID (Feb 27): <[EMAIL PROTECTED]> > + > + - fix up ap_get_brigade() semantics, fix bug in DECHUNK / > +ap_getline. many messages (plus their threads) (Apr/May): > + Message-ID: <[EMAIL PROTECTED]> > + Message-ID: <[EMAIL PROTECTED]> > + Message-ID: <[EMAIL PROTECTED]> > + > + - further work with combining/tweaking the builtin filters: > + Message-ID: <[EMAIL PROTECTED]> > + > >RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: > > > > -- Greg Stein, http://www.lyra.org/
Re: [Fwd: Changes to Apache for Solaris2.8]
Rodent of Unusual Size wrote: > > > Now they are demanding the change.. Not acked. Anyone > want to take this up with them? I can, because I certainly don't see *anything* like that on any of my Solaris 8 systems. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither"
[jpbox@pacbell.net: FW: New Apache Installer]
Not acked. Unclear whether this is for Windows or what.. - Forwarded message from "J. Phul" <[EMAIL PROTECTED]> - From: "J. Phul" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: FW: New Apache Installer Date: Fri, 14 Sep 2001 23:46:24 -0700 Importance: Normal I've gone through the FAQs again and didn't see a place to go to directly. The message is short and understand everyone's time is valuable. Please read the e-mail below and let me know if this is valuable to the overall project. ~jerry -Original Message- From: J. Phul [mailto:[EMAIL PROTECTED]] Sent: Friday, September 14, 2001 11:33 PM To: [EMAIL PROTECTED] Subject: New Apache Installer To Whom It May Concern, I've written a new installer in addition to the one you already have. Basically it offers a simple command line interface which installs: - apache - mod ssl (and all sub-packages) - php - db2 or mysql support. I'm sure this could be a good installer the public domain can use but am not sure where it can live. I have no issues for putting the necessary files on my site for now. I can't imagine the traffic being that large. As far as a link and making people aware of it, I don't know if there is a place for something like that on your or other sites??? ~jerry P.S. I will eventually write an HTML interface for people to run installs. I'm already playing with a beta script for that. - End forwarded message - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
