Re: A question for the protocol gurus...
Roy T. Fielding wrote: It can fail however it likes -- transparent gateways are not allowed in HTTP. Once you violate the protocol, you are doomed to any number of unspecified workarounds that will ultimately fail outside the common case. Makes sense. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: daedalus is running 2.0.31
Ian Holsman wrote: Greg Ames wrote: ...since Thursday, 31-Jan-2002 19:04:06 PST. Cool. Something hangs now on daedalus! we're running it for our developers internally starting tomorrow. Beside checking out the tag, it has the usual patch to save the input buffers for debugging, and a quick-n-dirty hack to exit the child without killing the parent if accept() gets ENFILE (system out of fd's). I did have to futz with the config file a bit. The main thing was the change from mod_auth_db to mod_auth_dbm. I hope the following is correct, please holler if not: @@ -762,7 +764,8 @@ Options All /Directory Directory /da1/www/bugs.apache.org/private - AuthDBUserFile /home/apmail/bugdbaccounts + AuthDBMUserFile /home/apmail/bugdbaccounts + AuthDBMType DB your running berkeleyDB ??? if so that is the right config. AuthName ApacheBugDatabaseUsers AuthType Basic require valid-user Are there any changes to the utility to manage the passwords that Brian and Manoj should know about? htdbm has been changed as well so as to allow for multiple DB types I think it is -T DB as an extra parameter if you don't have berkeleyDB support as default. --Ian Greg
Re: 1.3 weirdness with AcceptMutex on Solaris
Bill Stoddard wrote: If httpd is linked sans thread libs, then calling these functions should always return true, but not actually acomplish anything intended. :-OOO I'm not sure *what* the surprise emoticon is, but I'm ditto. It appears that there are basically null-stubs in libc for various pthread functions. Supremely bogus. First fix would be to always add -lpthread but the what we should really do is test if we are compiling with the PTHREAD mutex and only add then. -- === 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 - T.Jefferson
Building latest httpd-2.0
I'm in the processing of building from the latest httpd-2.0 sources and found the following errors... I'm building with mod_ssl support and have copied the openssl directory (the results of my building openssl) into the srclib directory. The mod_ssl.dsp is set up to look in .../openssl/inc32/... for include files. When I build openssl, I have a directory named include, not inc32. While easy to change, I have not found any instructions that state this is necessary. So... am I configuring something incorrectly, or should this be changed. I've also noticed that the mod_ssl.dsp is not able to find the ssleay32.lib and libeay.lib files, which are in my openssl/lib path. Is this my bad, or does the dsp need to be corrected? Tks Dwayne
Re: daedalus is running 2.0.31
jean-frederic clere wrote: Ian Holsman wrote: Greg Ames wrote: ...since Thursday, 31-Jan-2002 19:04:06 PST. Cool. Something hangs now on daedalus! yep. It ran for nearly 5 hours. Then the clock struck midnight, a cron job kicked off a graceful restart, and: [Fri Feb 01 00:00:04 2002] [notice] Apache/2.0.31 (Unix) configured -- resuming normal operations [Fri Feb 01 00:00:04 2002] [notice] seg fault or similar nasty error detected in the parent process ...and we were down until I woke up, took a look, momentarily panicked, then put us back on 2.0.29 at Friday Feb 01 05:18:04 daedalus time. At least we have a both a log message and a coredump now. That wasn't the case not too long ago. The dump is /usr/local/apache2.0.31/corefiles/httpd.core.1 . The backtrace is pretty simple: #0 0x806fdeb in find_child_by_pid (pid=0xbfbffa4c) at scoreboard.c:355 #1 0x8063e9a in ap_mpm_run (_pconf=0x8099010, plog=0x80bf010, s=0x809a8d8) at prefork.c:1078 #2 0x8069676 in main (argc=1, argv=0xbfbffb30) at main.c:498 #3 0x805d95d in _start () Greg (writes on the blackboard 50 times:) I will test graceful restart I will test graceful restart I will test graceful restart ...
httpd 2.0 problem with ap_get_client_block
We are experiencing a problem with ap_get_client_block where a module (Tomcat in this instance) is calling ap_get_client_block() to read stdin and the last read (the one where we get back 0 bytes) is hanging for Timeout time before returning. I did some investigation in http_protocol.c in ap_get_client_block and it talks about managing r-remaining. I checked httpd 1.3.x and see that is does indeed manage this, but this logic is missing from httpd 2.0. I am guessing that this may be part of a work-in-progress based on the section in the status revamp the input filter behavior, but thought I would post to make sure it isn't being overlooked. Kent Bruinsma [EMAIL PROTECTED]
Re: daedalus is running 2.0.31
On Fri, Feb 01, 2002 at 10:20:09AM -0500, Greg Ames wrote:
yep. It ran for nearly 5 hours. Then the clock struck midnight, a cron job
kicked off a graceful restart, and:
...all the horses turned back into mice... ;)
[Fri Feb 01 00:00:04 2002] [notice] Apache/2.0.31 (Unix) configured -- resuming
normal operations
[Fri Feb 01 00:00:04 2002] [notice] seg fault or similar nasty error detected in
the parent process
...and we were down until I woke up, took a look, momentarily panicked, then put
us back on 2.0.29 at Friday Feb 01 05:18:04 daedalus time.
At least we have a both a log message and a coredump now. That wasn't the case
not too long ago. The dump is /usr/local/apache2.0.31/corefiles/httpd.core.1 .
The backtrace is pretty simple:
#0 0x806fdeb in find_child_by_pid (pid=0xbfbffa4c) at scoreboard.c:355
#1 0x8063e9a in ap_mpm_run (_pconf=0x8099010, plog=0x80bf010, s=0x809a8d8)
at prefork.c:1078
#2 0x8069676 in main (argc=1, argv=0xbfbffb30) at main.c:498
#3 0x805d95d in _start ()
I have a feeling the scoreboard is getting destroyed by it's pool cleanup
routine before this routine gets called:
(gdb) p ap_scoreboard_image-parent
$2 = (process_score *) 0x2823500c
(gdb) p i
$3 = 0
(gdb) p ap_scoreboard_image-parent[0]
Cannot access memory at address 0x2823500c.
Did we intend to reuse the scoreboard across restarts, or recreate it?
It looks like the scoreboard is currently being created in the pconf
pool, which is cleared shortly after ap_run_mpm() decides to do a graceful.
OTOH, we don't call ap_run_pre_mpm() to create the scoreboard if we are
doing a graceful restart. I think that's where the SEGV is comming from.
-aaron
BTW, if we're ok to recreate during restart, I think this would fix prefork
(untested):
Index: server/mpm/prefork/prefork.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.236
diff -u -u -r1.236 prefork.c
--- server/mpm/prefork/prefork.c30 Jan 2002 22:35:56 - 1.236
+++ server/mpm/prefork/prefork.c1 Feb 2002 15:57:38 -
@@ -1000,10 +1000,8 @@
}
SAFE_ACCEPT(accept_mutex_init(pconf));
-if (!is_graceful) {
-if (ap_run_pre_mpm(pconf, SB_SHARED) != OK) {
-return 1;
-}
+if (ap_run_pre_mpm(pconf, SB_SHARED) != OK) {
+return 1;
}
#ifdef SCOREBOARD_FILE
else {
Re: httpd 2.0 problem with ap_get_client_block
On Mon, Jan 28, 2002 at 11:37:09AM -0600, RCHAPACH Rochester wrote: We are experiencing a problem with ap_get_client_block where a module (Tomcat in this instance) is calling ap_get_client_block() to read stdin and the last read (the one where we get back 0 bytes) is hanging for Timeout time before returning. I did some investigation in http_protocol.c in ap_get_client_block and it talks about managing r-remaining. I checked httpd 1.3.x and see that is does indeed manage this, but this logic is missing from httpd 2.0. I am guessing that this may be part of a work-in-progress based on the section in the status revamp the input filter behavior, but thought I would post to make sure it isn't being overlooked. Well, it should work. I *believe* that httpd-test tests POSTs via ap_get_client_block, so... How is the body sent? Content-Length? Chunked? Or, Connection: Close? The idea is that ap_http_filter should be quickly returning when we have read past the end of the body. It sounds like ap_http_filter isn't detecting when EOS should occur. -- justin
Re: daedalus is running 2.0.31
Aaron Bannert wrote: On Fri, Feb 01, 2002 at 10:20:09AM -0500, Greg Ames wrote: yep. It ran for nearly 5 hours. Then the clock struck midnight, a cron job kicked off a graceful restart, and: ...all the horses turned back into mice... ;) hee, hee :) very appropriate I have a feeling the scoreboard is getting destroyed by it's pool cleanup routine before this routine gets called: (gdb) p ap_scoreboard_image-parent $2 = (process_score *) 0x2823500c (gdb) p i $3 = 0 (gdb) p ap_scoreboard_image-parent[0] Cannot access memory at address 0x2823500c. Did we intend to reuse the scoreboard across restarts, or recreate it? Reuse it. I think it would be cool if we could recreate it, but we are not there yet. The problem is that after a graceful restart, we don't know when the guys in third world countries with 28.8Kb modems and noisy phone lines will be done downloading the latest 4.6MB tomcat nightly build. We can't free the scoreboard until all of the old generation children go away, and that's complex to figure out, so we reuse it. It looks like the scoreboard is currently being created in the pconf pool, which is cleared shortly after ap_run_mpm() decides to do a graceful. That sounds bad. Greg
where does apache fork a new cgi process?
Hello, can anyone, please, point out where apache forks a new process in order to run a new cgi script? I want to make it count and limit the number of cgi scripts on per user basis, because RLimit* directives and various suexec patches don't prevent it from starting new processes. I run apache on FreeBSD 4.4 thanks in advance, Kirill Klypin [EMAIL PROTECTED] _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: daedalus is running 2.0.31
Aaron Bannert wrote: On Fri, Feb 01, 2002 at 11:26:47AM -0500, Greg Ames wrote: It looks like the scoreboard is currently being created in the pconf pool, which is cleared shortly after ap_run_mpm() decides to do a graceful. That sounds bad. Switched to use a global pool, and this gets rid of the SEGVs for me on graceful. Ian: you may wish to push the tag up on this file, but it's up to you. -aaron pushing it now. (luckily we haven't rolled yet eh)
Re: httpd 2.0 problem with ap_get_client_block
Justin Erenkrantz wrote: On Mon, Jan 28, 2002 at 11:37:09AM -0600, RCHAPACH Rochester wrote: We are experiencing a problem with ap_get_client_block where a module (Tomcat in this instance) is calling ap_get_client_block() to read stdin and the last read (the one where we get back 0 bytes) is hanging for Timeout time before returning. I did some investigation in http_protocol.c in ap_get_client_block and it talks about managing r-remaining. I checked httpd 1.3.x and see that is does indeed manage this, but this logic is missing from httpd 2.0. I am guessing that this may be part of a work-in-progress based on the section in the status revamp the input filter behavior, but thought I would post to make sure it isn't being overlooked. Well, it should work. I *believe* that httpd-test tests POSTs via ap_get_client_block, so... How is the body sent? Content-Length? Chunked? Or, Connection: Close? h...chunked...it could be broken on ebcdic boxes now, due to the changes in the input filtering and ap_getline. It used to be that every byte of inbound http protocol data went thru ap_getline and got translated if the source code charset wasn't ascii. I don't know if that's true for chunk headers any more. We also had some breakage with long timeouts for POSTs on all platforms a while back, I think before 2_0_28. Kent, what level of base Apache are we talking about here? Greg The idea is that ap_http_filter should be quickly returning when we have read past the end of the body. It sounds like ap_http_filter isn't detecting when EOS should occur. -- justin
Re: cvs commit: httpd-2.0 STATUS
On Fri, Feb 01, 2002 at 05:51:18PM -, [EMAIL PROTECTED] wrote: jerenkrantz02/02/01 09:51:18 Modified:.STATUS Log: There are really two issues here: - Can we *ever* build a static binary? That *is* a showstopper, I agree. And, Aaron has volunteered to fix this soon-ish. - Separate from that, is the question whether we should we *always* build a static binary? That I do not believe I *is* a showstopper. So, let's make the distinction and call for a vote. I split this out (but left Ken's comment about the default where it was) as it really is two issues as cited above. We've gone over the enable static binaries by default on the list. I don't care to discuss this more. Please vote if you care. And, if you aren't aware, we've been adding lots of vote calls in the last 24 hours as we're trying to clean up STATUS to pave the way for a release without any showstoppers present. Even if you aren't a committer, please feel free to cast your votes for items in STATUS - they aren't technically binding, but we can take them into consideration. I will attempt to record them as such in STATUS with the appropriate notations. -- justin
Re: cvs commit: httpd-2.0/server scoreboard.c
On Fri, Feb 01, 2002 at 11:00:11AM -0700, Brad Nicholes wrote: Why is the platform #ifdef WIN32 being included in an HTTPD source file? I thought the whole idea was to keep platform specific code out of the general HTTPD source and put it in APR. It is admittedly lame, but it is only temporary. I have a fix in the works that makes this completely platform neutral, but I'm waiting to test and apply until after our current tag/release cycle (and until I have more time). -aaron
Re: httpd 2.0 problem with ap_get_client_block
On Fri, Feb 01, 2002 at 12:55:48PM -0500, Greg Ames wrote: h...chunked...it could be broken on ebcdic boxes now, due to the changes in the input filtering and ap_getline. It used to be that every byte of inbound http protocol data went thru ap_getline and got translated if the source code charset wasn't ascii. I don't know if that's true for chunk headers any more. Yeah, I think EBCDIC boxes may be broken in ap_rgetline. I posted asking for people with those boxes to give feedback. No one responded. I don't think not having EBCDIC support would stop a beta or even a GA perhaps. =) I will add an item to STATUS about the EBCDIC now to remind us that it may not work. -- justin
Re: httpd 2.0 problem with ap_get_client_block
Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 12:55:48PM -0500, Greg Ames wrote: h...chunked...it could be broken on ebcdic boxes now, due to the changes in the input filtering and ap_getline. It used to be that every byte of inbound http protocol data went thru ap_getline and got translated if the source code charset wasn't ascii. I don't know if that's true for chunk headers any more. Yeah, I think EBCDIC boxes may be broken in ap_rgetline. I posted asking for people with those boxes to give feedback. No one responded. all the 2.0 ebcdic guys I know have been kinda busy lately... I will add an item to STATUS about the EBCDIC now to remind us that it may not work. -- justin It might be a piece of cake fix. Is it true that inbound chunk headers no longer go thru ap_[r]getline? Greg
Re: cvs commit: httpd-2.0/server scoreboard.c
Just checking. Thanks, [EMAIL PROTECTED] Friday, February 01, 2002 11:26:30 AM From: Brad Nicholes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 01, 2002 12:00 PM Subject: Re: cvs commit: httpd-2.0/server scoreboard.c Why is the platform #ifdef WIN32 being included in an HTTPD source file? I thought the whole idea was to keep platform specific code out of the general HTTPD source and put it in APR. Brad, the Unix code is wrong, but it clobbered Win32 (which could not create a NULL sharemem at that moment.) Now Win32 supports unnamed scoreboards, so that code _could_ go away; however... Aaron is working on reverting to use-named-scoreboard if a name is given in the conf file, or anon (unnamed) shm otherwise. When that patch goes into the Unix MPM's - this code may all be reverted to the Win32 path here. Yes - platforms do NOT belong in the httpd sources. For a temporary and quick fix, however, this is prefereable to having entirely broken platforms :) Bill
Re: PHP42/Zend update needed for Apache 2.0.31
These are the steps I take to build it rm -rf php cvs co php4 cd php4 cvs co Zend TSRM cd .. ./buildconf ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs --enable-safe-mode \ --with-openssl=/usr/src/openssl-0.9.6c/ --enable-magic-quotes --with-zlib \ --with-bz2 --enable-calendar --enable-gd-native-ttf --with-ttf \ --with-imap=/usr/src/imap-2001a.RELEASE-CANDIDATE.4/ --with-mysql=no \ --with-imap-ssl --enable-mailparse --with-pgsql --enable-trans-sid \ --enable-shmop --with-snmp=shared --enable-ucd-snmp-hack --enable-sysvsem \ --enable-sysvshm --enable-memory-limit \ --with-freetype-dir=/usr/local/include/freetype1/ --with-jpeg-dir=shared \ --with-png-dir=shared --with-xpm-dir=shared --with-gd-dir=shared \ --with-gd \ LIBS=-ljpeg -lpng \ LDFLAGS=-L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/ssl/lib \ CFLAGS=$CFLAGS -pipe -g -I/usr/local/include CPPFLAGS=$CFLAGS make -j2 LDFLAGS=-L/usr/local/ssl/lib David Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 01:28:50PM -0500, David Ford wrote: I can build php fine (did you do the php/Zend and php/TSRM checkout/update?), I just haven't had much luck in the past two weeks getting apache to startup with php installed. Nuttin' but segfaults Jim. Yeah, I have those dirs. You can run buildconf and configure and it produces all of the relevant Makefiles? Odd, because it isn't doing that here. -- justin
Re: cvs commit: httpd-2.0 ABOUT_APACHE
Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 06:21:59AM -, [EMAIL PROTECTED] wrote: jerenkrantz02/01/31 22:21:59 Modified:.ABOUT_APACHE Log: Update some of the URLs and notes that have gotten stale. Ian, This one might be worth bumping the tag on. Considering someone might actually read our docs. =) -- justin final one. barring some major calamity.. this is what I'm going to release as a alpha.
Re: daedalus is running 2.0.31
Aaron Bannert wrote: Switched to use a global pool, and this gets rid of the SEGVs for me on graceful. Ian: you may wish to push the tag up on this file, but it's up to you. daedalus has been updated, and graceful and non-graceful restarts are working fine once again. I'll probably try it live again tonight. Thanks, Aaron and Ian. Greg
Re: cvs commit: httpd-2.0 STATUS
From: [EMAIL PROTECTED] Sent: Friday, February 01, 2002 7:21 AM coar02/02/01 05:21:34 Modified:.STATUS @@ -135,7 +142,7 @@ on dev@apr: Message-ID: [EMAIL PROTECTED] Vote: Is a non-portable perchild going to hold up a GA release? -Yes: +Yes: Ken No: Aaron, Justin, trawick I have to strongly object to this Ken's assertion. This could be a feature of a minor bump. perchild is certainly a terrific feature. However, we have (in no particular order); * portability and great optimization (for non-unix) via APR * threaded MPM * filters * new modules (many experimental) * better hooks and APIs for module authors. So we will hold up GA for a new feature [perchild]? But they want it cannot be the basis for GA. Heck, folks want ASP ... that doesn't mean we drop it all until this feature is offered by someone. Perchild is a great example of what MPMs were designed for!!! But this is _not_ a showstopper to put Apache2.0 in administrators' hands.
Re: cvs commit: httpd-2.0 STATUS
Bill, thanks for the update! But let's consider this, instead. Create an 'info' shm (like Havard has), that contains all the goodies about the parent, and has room for the child to 'talk back' at the parent. These include listeners, the score shm handle, logfile handles or whatever. Fill it with Parent handles. Give every child an inherited handle to the parent with _all_ permissions along with an inherited handle to this shm (and perhaps a lock handle as well.) Each child duplicates the parent's handles into it's own space, then for security, closes the _all_ permissions handle to the parent. Now the child can't harm the parent, it finished all the work of sharing the handles (leaving the parent free to be spawning more than one child, at some point in the future), a single list of the handles can be used by all the processes, and they can deposit notes in the shm. Bill * Win32: Rotatelogs sometimes is not terminated when Apache goes down hard. FirstBill was looking at possibly tracking the child's-child processes in the parent process. -OtherBill asks, wasn't this fixed? -OtherBill asks again, what is the status? +OtherBill asks, wasn't this fixed? + stoddard: Not fixed. Shared scoreboard might offer a good + way for the parent to keep track of 'other child' processes + and whack them if the child goes down. * Win32: Add a simple hold console open patch (wait for close or the ESC key, with a nice message) if the server died a bad
Re: cvs commit: httpd-2.0 STATUS
William A. Rowe, Jr. wrote: I have to strongly object to this Ken's assertion. Um, you're objecting to my opinion. Why not try, Ken, I think you're wrong and here's why rather than, lookit, everybody, here's why Ken's wrong? As in addressing me in the second person rather than the third? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millenium hand and shrimp!
Re: httpd 2.0 problem with ap_get_client_block
Greg Ames wrote: Yeah, I think EBCDIC boxes may be broken in ap_rgetline. I posted asking for people with those boxes to give feedback. No one responded. It might be a piece of cake fix. Is it true that inbound chunk headers no longer go thru ap_[r]getline? (yeah I know, find and grep are my friends.) I just eyeballed ap_http_filter, and it looks like every inbound chunk header is still read via ap_getline, so that part looks fine. Greg
Re: 1.3 weirdness with AcceptMutex on Solaris
Jim Jagielski [EMAIL PROTECTED] writes: Bill Stoddard wrote: If httpd is linked sans thread libs, then calling these functions should always return true, but not actually acomplish anything intended. :-OOO I'm not sure *what* the surprise emoticon is, but I'm ditto. It appears that there are basically null-stubs in libc for various pthread functions. Supremely bogus. First fix would be to always add -lpthread but the what we should really do is test if we are compiling with the PTHREAD mutex and only add then. I'm not sure why we'd need to test. Current code says that if it is Solaris then we define HAVE_PTHREAD_SERIALIZED_ACCEPT. I changed Configure yesterday to unconditionally add -lpthread (it looks to me that we get -lthread for free since -lpthread is a wrapper???). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0 STATUS
From: Rodent of Unusual Size [EMAIL PROTECTED] Sent: Friday, February 01, 2002 2:11 PM William A. Rowe, Jr. wrote: I have to strongly object to this Ken's assertion. Um, you're objecting to my opinion. Why not try, Ken, I think you're wrong and here's why rather than, lookit, everybody, here's why Ken's wrong? As in addressing me in the second person rather than the third? Sorry that Bill phrased it that way, Ken. He respects your judgement, but respectfully disagree with you on this particular point. Bill sees how this really would rub someone the wrong way :) [/this Ken's/ should have been /this/ or /Ken's/ - simple typo, I don't remember which I typed first and which I added (meaning to kill the other.]
Re: 1.3 weirdness with AcceptMutex on Solaris
Jeff Trawick wrote: Jim Jagielski [EMAIL PROTECTED] writes: Bill Stoddard wrote: If httpd is linked sans thread libs, then calling these functions should always return true, but not actually acomplish anything intended. :-OOO I'm not sure *what* the surprise emoticon is, but I'm ditto. It appears that there are basically null-stubs in libc for various pthread functions. Supremely bogus. First fix would be to always add -lpthread but the what we should really do is test if we are compiling with the PTHREAD mutex and only add then. I'm not sure why we'd need to test. Current code says that if it is Solaris then we define HAVE_PTHREAD_SERIALIZED_ACCEPT. I changed Configure yesterday to unconditionally add -lpthread (it looks to me that we get -lthread for free since -lpthread is a wrapper???). Yeah yer right. If they know to disable HAVE_PTHREAD_SERIALIZED_ACCEPT then they know to remove the -lpthread... or not to if they want. -- === 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 - T.Jefferson
Apache 2_0_31 is now rolled
and available on http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz Many thanks to Justin Aaron. can people do a quick sanity check that the roll is good TIA Ian
Re: Apache 2_0_31 is now rolled
httpd-2.0.31 does not build on NetWare because of a screwed up #ifdef APR_HAS_SHARED_MEMORY in scoreboard.c/ap_reopen_scoreboard(). The fix for this has already been checked in but I'm not going to worry about it for now as long as 2.0.31 is just an alpha. If you are planning on releasing .31 as beta or GA, then the fix definitely needs to be included. From here on out, NetWare is good to go! Yeah!! Brad [EMAIL PROTECTED] Friday, February 01, 2002 1:39:39 PM and available on http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz Many thanks to Justin Aaron. can people do a quick sanity check that the roll is good TIA Ian
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 02:45:56PM -0700, Brad Nicholes wrote: httpd-2.0.31 does not build on NetWare because of a screwed up #ifdef APR_HAS_SHARED_MEMORY in scoreboard.c/ap_reopen_scoreboard(). The fix for this has already been checked in but I'm not going to worry about it for now as long as 2.0.31 is just an alpha. If you are planning on releasing .31 as beta or GA, then the fix definitely needs to be included. From here on out, NetWare is good to go! Yeah!! We are definately trying to make this a beta. Perhaps Ian can be pursuaded (with money, food, etc..) to do a reroll, or we could wait a few days and try again. An alternative is to post the patch in the release notes (it is a very small patch). -aaron
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 02:45:56PM -0700, Brad Nicholes wrote: httpd-2.0.31 does not build on NetWare because of a screwed up #ifdef APR_HAS_SHARED_MEMORY in scoreboard.c/ap_reopen_scoreboard(). The fix for this has already been checked in but I'm not going to worry about it for now as long as 2.0.31 is just an alpha. If you are planning on releasing .31 as beta or GA, then the fix definitely needs to be included. From here on out, NetWare is good to go! Yeah!! We are definately trying to make this a beta. Perhaps Ian can be pursuaded (with money, food, etc..) to do a reroll, Once the tarball is rolled, that's it, move on to the next version. Bill
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 12:39:39PM -0800, Ian Holsman wrote: and available on http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz One note that Aaron pointed out is that the tarball extracts to apache_2.0.31 instead of httpd-2_0_31. Ian tarred it up as apache_2.0.31 instead of httpd-2_0_31 - the howto release page says to use apache_2.0.31, but AIUI, that's not our convention anymore - we use httpd-X_Y_Z now. So, I renamed the tarball when I placed it on daedalus, so that's my fault. But, that shouldn't stop us from beta status as its a packaging issue that is trivial to resolve. -- justin
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 01:48:59PM -0800, Aaron Bannert wrote: An alternative is to post the patch in the release notes (it is a very small patch). Since it only affects NetWare (how about Win32?), I'd be comfortable with having it as posted patch for 2.0.31 if it makes beta. We did this for 2.0.28 as well. -- justin
Re: Apache 2_0_31 is now rolled
Ian Holsman wrote: and available on http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz Many thanks to Justin Aaron. can people do a quick sanity check that the roll is good TIA Ian daedalus is unhappy when I run ./config.nice. I intentionally didn't run ./buildconf first so I could test the included configure scripts. Greg config.status: creating support/envvars-std mv: support/envvars-std: set owner/group (was: 1158/0): Operation not permitted config.status: creating support/log_server_status mv: support/log_server_status: set owner/group (was: 1158/0): Operation not permitted config.status: creating support/logresolve.pl mv: support/logresolve.pl: set owner/group (was: 1158/0): Operation not permitted config.status: creating support/phf_abuse_log.cgi mv: support/phf_abuse_log.cgi: set owner/group (was: 1158/0): Operation not permitted config.status: creating support/split-logfile mv: support/split-logfile: set owner/group (was: 1158/0): Operation not permitted config.status: creating build/rules.mk mv: build/rules.mk: set owner/group (was: 1158/0): Operation not permitted [bunches more of those earlier] config.status: creating include/ap_config_auto.h config.status: include/ap_config_auto.h is unchanged ./config.status: 775: Syntax error: done unexpected (expecting )) [gregames@daedalus httpd-2.0.31]$
Re: Apache 2_0_31 is now rolled
Bill Stoddard wrote: We are definately trying to make this a beta. Perhaps Ian can be pursuaded (with money, food, etc..) to do a reroll, Once the tarball is rolled, that's it, move on to the next version. This is a very error prone part of our process. I got around it in 2_0_28 by sending preliminary tarballs to people on platforms I knew were problematic, before making anything public. Madhu told me my first tarball built with autoconf 1.4.2 didn't work for HP-UX. So I re-rolled on daedalus for most platforms, and on Linux w/autoconf 1.4.2 for Darwin. Greg
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 04:58:00PM -0500, Greg Ames wrote: daedalus is unhappy when I run ./config.nice. I intentionally didn't run ./buildconf first so I could test the included configure scripts. Greg config.status: creating support/envvars-std mv: support/envvars-std: set owner/group (was: 1158/0): Operation not permitted Sounds like permission problems. Perhaps you need to extract it without a the user-id in the tarballs? -- justin
Re: Apache 2_0_31 is now rolled
Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 04:58:00PM -0500, Greg Ames wrote: daedalus is unhappy when I run ./config.nice. I intentionally didn't run ./buildconf first so I could test the included configure scripts. Greg config.status: creating support/envvars-std mv: support/envvars-std: set owner/group (was: 1158/0): Operation not permitted Sounds like permission problems. Perhaps you need to extract it without a the user-id in the tarballs? -- justin where to from here? do we just trash-31 as the tar ball is INVALID ? do we start this game again with 32? or should we do a 31.1 ?
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 02:26:14PM -0800, Ian Holsman wrote: where to from here? do we just trash-31 as the tar ball is INVALID ? do we start this game again with 32? or should we do a 31.1 ? I think people have said its okay to reroll if we screw up the roll. But, I'm not sure. FWIW, Roy mentioned there is a script in httpd-2.0 that generates the tarballs automatically. I think it's httpd_roll_release. Try that instead. -- justin
RE: Apache 2_0_31 is now rolled
Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 04:58:00PM -0500, Greg Ames wrote: daedalus is unhappy when I run ./config.nice. I intentionally didn't run ./buildconf first so I could test the included configure scripts. Greg config.status: creating support/envvars-std mv: support/envvars-std: set owner/group (was: 1158/0): Operation not permitted Sounds like permission problems. Perhaps you need to extract it without a the user-id in the tarballs? -- justin where to from here? do we just trash-31 as the tar ball is INVALID ? do we start this game again with 32? or should we do a 31.1 ? Just re-roll 31. As long as the code isn't changed, we are fine to re-roll tarballs. The goal is that the tarballs are easy to produce, using tags that we control. The biggest problem is that the rolling_a_release page is horribly out of date, and it is completely invalid. All you have to do to roll a release is: ssh cvs.apache.org cvs co httpd-2.0 cp httpd-2.0/build/httpd_roll_release . ./httpd_roll_release TAG_NAME logfile_name user The TAG_NAME is the tag to use to check out the source. Logfile_name is a log file to use to capture all of the output User is your user ID, which the script uses to correctly sign the release. If you key files are setup correctly, you most likely do not need that argument. If you use those four steps, your builds should just work. If they don't, then we need to fix the rolling script so that it does just work. Ryan
Re: Apache 2_0_31 is now rolled
why not just reroll as 2.0.31pl1? On Fri, 1 Feb 2002, Greg Ames wrote: Bill Stoddard wrote: We are definately trying to make this a beta. Perhaps Ian can be pursuaded (with money, food, etc..) to do a reroll, Once the tarball is rolled, that's it, move on to the next version. This is a very error prone part of our process. I got around it in 2_0_28 by sending preliminary tarballs to people on platforms I knew were problematic, before making anything public. Madhu told me my first tarball built with autoconf 1.4.2 didn't work for HP-UX. So I re-rolled on daedalus for most platforms, and on Linux w/autoconf 1.4.2 for Darwin. Greg
Re: Apache 2_0_31 is now rolled
Justin Erenkrantz wrote: On Fri, Feb 01, 2002 at 04:58:00PM -0500, Greg Ames wrote: daedalus is unhappy when I run ./config.nice. I intentionally didn't run ./buildconf first so I could test the included configure scripts. Greg config.status: creating support/envvars-std mv: support/envvars-std: set owner/group (was: 1158/0): Operation not permitted Sounds like permission problems. Perhaps you need to extract it without a the user-id in the tarballs? -- justin It works fine when I do ./buildconf first. Jeff stuck his head in here before he left and said that autoconf 2.52 doesn't work on FreeBSD -- he recognized the ./config.status: 775: Syntax error: done unexpected (expecting )) error. Greg
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 05:37:29PM -0500, Greg Ames wrote: It works fine when I do ./buildconf first. Jeff stuck his head in here before he left and said that autoconf 2.52 doesn't work on FreeBSD -- he recognized the ./config.status: 775: Syntax error: done unexpected (expecting )) I think this roll will be done on icarus instead of on Ian's machine, so it'll get autoconf-2.13. Bear with us. =) -- justin
Re: Apache 2_0_31 is now rolled
Greg Ames [EMAIL PROTECTED] writes: This is a very error prone part of our process. I got around it in 2_0_28 by sending preliminary tarballs to people on platforms I knew were problematic, before making anything public. Madhu told me my first tarball built with autoconf 1.4.2 didn't work for HP-UX. So I re-rolled on daedalus for most platforms, and on Linux w/autoconf 1.4.2 for Darwin. I think Greg mean libtool 1.4.2. AIX definitely needs libtool 1.4.2. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Apache 2_0_31 is now rolled
Ryan Bloom [EMAIL PROTECTED] writes: All you have to do to roll a release is: ssh cvs.apache.org cvs co httpd-2.0 and apr and apr-util I would guess cp httpd-2.0/build/httpd_roll_release . ./httpd_roll_release TAG_NAME logfile_name user -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Apache 2_0_31 is now rolled
Jeff Trawick wrote: Ryan Bloom [EMAIL PROTECTED] writes: All you have to do to roll a release is: ssh cvs.apache.org cvs co httpd-2.0 and apr and apr-util I would guess cp httpd-2.0/build/httpd_roll_release . ./httpd_roll_release TAG_NAME logfile_name user ok. I used this method and generated the tarballs on cvs.apache.org I don't have access to daedulus so before the tarball has been places in http://www.apache.org/~jerenkrantz/2.0.31
Re: httpd 2.0 problem with ap_get_client_block
RCHAPACH Rochester wrote: We are experiencing a problem with ap_get_client_block where a module (Tomcat in this instance) is calling ap_get_client_block() to read stdin and the last read (the one where we get back 0 bytes) is hanging for Timeout time before returning. Kent Bruinsma [EMAIL PROTECTED] Just got off the phone with Kent. He called me because he's got a 4 day outbound email lag before his posts show up on the list (???) and wanted to save us some time. This turned out to be a Tomcat bug. It was calling ap_get_client_block an extra time, causing an extra read which timed out. He's working on 2.0.31 or something close, and ebcdic translation is still working fine. He had to work his way thru the input side code in order to figure out what was happening, and liked the look of the code. So congratulations, Justin, nice job! Greg
Re: Apache 2_0_31 is now rolled
Jeff Trawick wrote: Greg Ames [EMAIL PROTECTED] writes: Madhu told me my first tarball built with autoconf 1.4.2 didn't work for HP-UX. So I re-rolled on daedalus for most platforms, and on Linux w/autoconf 1.4.2 for Darwin. I think Greg mean libtool 1.4.2. yep...it's been a long day. AIX definitely needs libtool 1.4.2. news to me. Greg
RE: Apache 2_0_31 is now rolled
Hi, Pending re-rolling of the tar file, here's what I got for the curent version of httpd-2_0_31-alpha.tar.gz : creating config_vars.mk configure: creating ./config.status creating modules/aaa/Makefile creating modules/cache/Makefile creating modules/echo/Makefile creating modules/experimental/Makefile creating modules/filters/Makefile creating modules/loggers/Makefile creating modules/metadata/Makefile creating modules/proxy/Makefile creating modules/ssl/Makefile creating modules/test/Makefile cat: Cannot open /proj/middleware/madhum/PA/apache_2.0.31/modules/test/Makefile.in: No such file or directory creating os/unix/Makefile [...] -Madhu -Original Message- From: Greg Ames [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: Re: Apache 2_0_31 is now rolled Jeff Trawick wrote: Greg Ames [EMAIL PROTECTED] writes: Madhu told me my first tarball built with autoconf 1.4.2 didn't work for HP-UX. So I re-rolled on daedalus for most platforms, and on Linux w/autoconf 1.4.2 for Darwin. I think Greg mean libtool 1.4.2. yep...it's been a long day. AIX definitely needs libtool 1.4.2. news to me. Greg
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 03:08:19PM -0800, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: Hi, Pending re-rolling of the tar file, here's what I got for the curent version of httpd-2_0_31-alpha.tar.gz : creating config_vars.mk configure: creating ./config.status creating modules/aaa/Makefile creating modules/cache/Makefile creating modules/echo/Makefile creating modules/experimental/Makefile creating modules/filters/Makefile creating modules/loggers/Makefile creating modules/metadata/Makefile creating modules/proxy/Makefile creating modules/ssl/Makefile creating modules/test/Makefile cat: Cannot open /proj/middleware/madhum/PA/apache_2.0.31/modules/test/Makefile.in: No such file or directory creating os/unix/Makefile [...] Ian did the original roll by hand, and the how-to-release notes say to remove the test directory. Please disregard this tarball and if you're interested in testing the soon-to-be-alpha-and-we-hope-beta tarball, see http://www.apache.org/~jerenkrantz/2.0.31 thanks for testing, -aaron
Re: 1.3 weirdness with AcceptMutex on Solaris
On 1 Feb 2002, Jeff Trawick wrote: | I'm not sure why we'd need to test. Current code says that if it is | Solaris then we define HAVE_PTHREAD_SERIALIZED_ACCEPT. I changed | Configure yesterday to unconditionally add -lpthread (it looks to me | that we get -lthread for free since -lpthread is a wrapper???). Unconditionally adding in libpthread for code that doent need it means that there will be some performance hit due to the setup of thread-related things. This is per the URL from Sun that I included in the email I just sent. IMHO, we should make HPSA the default on Solaris. /dale
RE: Apache 2_0_31 is now rolled
All you have to do to roll a release is: ssh cvs.apache.org cvs co httpd-2.0 and apr and apr-util I would guess Nope. The script checks out the source that it will package. The only reason to checkout the httpd-2.0 repository is to get the httpd_roll_release script, so that should have read: cvs co httpd-2.0/build/httpd_roll_release Ryan cp httpd-2.0/build/httpd_roll_release . ./httpd_roll_release TAG_NAME logfile_name user -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Apache 2_0_31 is now rolled
So what is the verdict on the messed up #ifdef in scoreboard.c if .31 goes beta? Are we going to include the fixed version or patch it in the release notes? Brad [EMAIL PROTECTED] Friday, February 01, 2002 2:55:34 PM On Fri, Feb 01, 2002 at 01:48:59PM -0800, Aaron Bannert wrote: An alternative is to post the patch in the release notes (it is a very small patch). Since it only affects NetWare (how about Win32?), I'd be comfortable with having it as posted patch for 2.0.31 if it makes beta. We did this for 2.0.28 as well. -- justin
RE: Apache 2_0_31 is now rolled
Thanks, The build looks fine on HPUX (that was the problem with 2.0.28). -Madhu -Original Message- From: Aaron Bannert [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 3:12 PM To: [EMAIL PROTECTED] Subject: Re: Apache 2_0_31 is now rolled On Fri, Feb 01, 2002 at 03:08:19PM -0800, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: Hi, Pending re-rolling of the tar file, here's what I got for the curent version of httpd-2_0_31-alpha.tar.gz : creating config_vars.mk configure: creating ./config.status creating modules/aaa/Makefile creating modules/cache/Makefile creating modules/echo/Makefile creating modules/experimental/Makefile creating modules/filters/Makefile creating modules/loggers/Makefile creating modules/metadata/Makefile creating modules/proxy/Makefile creating modules/ssl/Makefile creating modules/test/Makefile cat: Cannot open /proj/middleware/madhum/PA/apache_2.0.31/modules/test/Makefile.in: No such file or directory creating os/unix/Makefile [...] Ian did the original roll by hand, and the how-to-release notes say to remove the test directory. Please disregard this tarball and if you're interested in testing the soon-to-be-alpha-and-we-hope-beta tarball, see http://www.apache.org/~jerenkrantz/2.0.31 thanks for testing, -aaron
Apache 2_0_31 is now rolled (take 2)
the NW patch is in there. the non-crap tarballs are in the /dist directory. who would have thought making a tar ball would be so hard. ..Ian
Re: httpd 2.0 problem with ap_get_client_block
So my post did show up... I thought it got lost, I sent it on Monday... Strange delay factor... I spent some additional time following the CVS's on this since last June and figured out what was going on. It is working, just not where I was initially looking. The module that was having this problem was calling ap_get_client_block 1 too many times. I was getting confused reading the comments in 2.0 because they still talk about r-remaining being important. Should have just read the code... Sorry for the confusion. Kent Bruinsma [EMAIL PROTECTED] On Mon, Jan 28, 2002 at 11:37:09AM -0600, RCHAPACH Rochester wrote: We are experiencing a problem with ap_get_client_block where a module (Tomcat in this instance) is calling ap_get_client_block() to read stdin and the last read (the one where we get back 0 bytes) is hanging for Timeout time before returning. I did some investigation in http_protocol.c in ap_get_client_block and it talks about managing r-remaining. I checked httpd 1.3.x and see that is does indeed manage this, but this logic is missing from httpd 2.0. I am guessing that this may be part of a work-in-progress based on the section in the status revamp the input filter behavior, but thought I would post to make sure it isn't being overlooked. Well, it should work. I *believe* that httpd-test tests POSTs via ap_get_client_block, so... How is the body sent? Content-Length? Chunked? Or, Connection: Close? The idea is that ap_http_filter should be quickly returning when we have read past the end of the body. It sounds like ap_http_filter isn't detecting when EOS should occur. -- justin
Re: Apache 2_0_31 is now rolled (take 2)
On Fri, Feb 01, 2002 at 04:46:58PM -0800, Ian Holsman wrote: the NW patch is in there. the non-crap tarballs are in the /dist directory. who would have thought making a tar ball would be so hard. No kidding. It'll be easier next time. After initially thinking there was a problem with graceful restarts on prefork, it just appears to takes about 6 seconds to complete a graceful restart cycle on my Linux 2.4.8 box. In the meantime, ps lists the children processes as defunct (which scared me off at first). But, after about 6 seconds, httpd starts serving again (incl. queued requests). Anyway, this delay looks defendable. I think this delay is acceptable, so I'm officially +1 on the 2.0.31 tarball for beta from: http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz Enjoy. -- justin
Re: Apache 2_0_31 is now rolled
On Fri, Feb 01, 2002 at 05:37:29PM -0500, Greg Ames wrote: ... It works fine when I do ./buildconf first. Jeff stuck his head in here before he left and said that autoconf 2.52 doesn't work on FreeBSD -- he recognized the ./config.status: 775: Syntax error: done unexpected (expecting )) I just checked in a fix for that, thanks to Zack Weinberg. Cheers, -g -- Greg Stein, http://www.lyra.org/
lose the underscores! (was: Apache 2_0_31 is now rolled (take 2))
On Fri, Feb 01, 2002 at 05:34:51PM -0800, Justin Erenkrantz wrote: ... http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz Why can't we name our damned tarballs and resulting directories like all other packages out there? For example: httpd-2.0.31-alpha.tar.gz unpacks into: ./httpd-2.0.31-alpha/ What is with the darn underscores? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: lose the underscores! (was: Apache 2_0_31 is now rolled (take 2)
According to Greg Stein: Why can't we name our damned tarballs and resulting directories like all other packages out there? For example: httpd-2.0.31-alpha.tar.gz unpacks into: ./httpd-2.0.31-alpha/ +1! ciao... -- Lars Eilebrecht - Don't hate yourself in the morning [EMAIL PROTECTED]- ...sleep till noon.
Re: lose the underscores! (was: Apache 2_0_31 is now rolled (take 2))
Greg Stein wrote: On Fri, Feb 01, 2002 at 05:34:51PM -0800, Justin Erenkrantz wrote: ... http://www.apache.org/dist/httpd/httpd-2_0_31-alpha.tar.gz Why can't we name our damned tarballs and resulting directories like all other packages out there? A superstitious behavior involving a fear of the Windows handling of extensions. One of those things I recall feeling strongly about at the time. - ben
Re: lose the underscores! (was: Apache 2_0_31 is now rolled (take 2)
Lars Eilebrecht wrote: According to Greg Stein: Why can't we name our damned tarballs and resulting directories like all other packages out there? For example: httpd-2.0.31-alpha.tar.gz unpacks into: ./httpd-2.0.31-alpha/ +1! I just built it with the ./httpd_roll_release script so if you don't like the underscores you should patch the script. I'm not going to change this roll (again) just for underscores. ciao...
Re: PHP42/Zend update needed for Apache 2.0.31
I can build php fine (did you do the php/Zend and php/TSRM checkout/update?), I just haven't had much luck in the past two weeks getting apache to startup with php installed. Nuttin' but segfaults Jim. David Justin Erenkrantz wrote: On Thu, Jan 31, 2002 at 04:15:38PM -0500, David Ford wrote: Apache 2.0.31 got tagged this evening, the php/zend code has been out of sync with it for a bit now. Would anyone mind chit chatting and getting the appropriate code updated? :) FWIW, I think DougM has made the appropriate input filtering changes and committed them to PHP's CVS repository almost immediately after my changes. So, I'm not really sure what could be wrong. I can't be of any help since it seems that PHP's HEAD is busted. configure isn't producing correct Makefiles. I looked at their commit logs yesterday and a commit made a few days ago changed the configure.in file (revision 1.295) and removed all generation of the top-level Makefiles among many others Makefiles (incl. sapi). So, I'm not even sure how you can even build their code in its current state. =( Doug or other PHP people have any clue here? Is something busted in PHP land or is buildconf no longer sufficient to generate the PHP configure scripts? -- justin
Re: PHP42/Zend update needed for Apache 2.0.31
On Fri, Feb 01, 2002 at 01:28:50PM -0500, David Ford wrote: I can build php fine (did you do the php/Zend and php/TSRM checkout/update?), I just haven't had much luck in the past two weeks getting apache to startup with php installed. Nuttin' but segfaults Jim. Yeah, I have those dirs. You can run buildconf and configure and it produces all of the relevant Makefiles? Odd, because it isn't doing that here. -- justin
