Re: MPMs, COW vs Child Process Spawning
Paul Querna wrote: Is COW ability of fork important enough with modern memory and operating systems, to maintain two significantly different code paths for spawning children processes? Background: One of the things I would like to do on the Simple MPM is unify how child processes are created on win32 and unix. On Win32, there is no fork, so roughly speaking what the current winnt MPM creates a new process, and feeds the configuration over a pipe to the new child. On Unix, all of the current MPMs use fork, and do not execute a new process, but instead then drop privileges and continue running. What I would like to do, is change Unix to use the same pattern as on Windows. I'm currently working on a portable apr process shared data using shared memory (See apr-dev list about the proposal) http://mail-archives.apache.org/mod_mbox/apr-dev/200804.mbox/[EMAIL PROTECTED] (Didn't get any replies to that, so it's either OK to proceed or it was totally non understandable ;) This could help unifying the platforms that need some sort of passing data between parent and child(s) Regards -- ^(TM)
Re: Simple MPM is in trunk
On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen [EMAIL PROTECTED] wrote: Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; I have to admit it isn't easy to do so. But it certainly is possible! Due to lack of time on my part I've not updated the httpd wiki but you can find how to do it here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 First few times are the hardest but once you setup a nice build environment its all good. Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the best, although 2008 works too. If you can't be bothered with the trouble, there are unofficial binaries on there too if you want to play with it. 2. Many stock modules have no 64-bit configuration. Again it's a matter of recompiling, most windows users are spoiled and thing everything comes in nice binaries. libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for 64-bit, most are easier to do than httpd itself. 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. ~Jorge
Re: MPMs, COW vs Child Process Spawning
Paul Querna wrote: I don't think the intention would be to use a single process on Unix -- we would still spawn multiple children -- they would just be created using fork+exec of the httpd binary, rather than just fork. This doesn't make sense - fork is far more efficient than fork+exec, we shouldn't be supporting the less efficient one for everybody just because it means less code. Instead we should try and fork, and if fork fails (eg Windows), or where configured (eg Leopard until Apple fixes it), it should fall back gracefully to fork+exec. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: MPMs, COW vs Child Process Spawning
On Wed 29 Oct 2008, Paul Querna wrote: Is COW ability of fork important enough with modern memory and operating systems, to maintain two significantly different code paths for spawning children processes? Don't know if it matters but mod_perl heavily relies on COW. Why drop a really valuable optimization? Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: Simple MPM is in trunk
Jorge Schrauwen wrote on 2008-10-30 17:03 On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen [EMAIL PROTECTED] wrote: Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; I have to admit it isn't easy to do so. But it certainly is possible! Due to lack of time on my part I've not updated the httpd wiki but you can find how to do it here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 First few times are the hardest but once you setup a nice build environment its all good. Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the best, although 2008 works too. If you can't be bothered with the trouble, there are unofficial binaries on there too if you want to play with it. 2. Many stock modules have no 64-bit configuration. Again it's a matter of recompiling, most windows users are spoiled and thing everything comes in nice binaries. libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for 64-bit, most are easier to do than httpd itself. Thanks for the nicely presented tutorial. I'll try to follow it and to understand what that 600+ PERL lines have fixed. So we have to get AWK, Bison, Flex and Sed to work, which are not required for a 32-bit build. And, we need a Perl Interpreter to run some magic conversions to get it built. That already made Win-x64 httpd a second-class citizen;) 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. The improvement is httpd's virtual memory -- and actually very significant: we need to map a 500+ GB index into the memory space of httpd's child process. 64-bit space is our only choice;) Bing
Re: MPMs, COW vs Child Process Spawning
On Wed, Oct 29, 2008 at 11:59:06AM -0700, Paul Querna wrote: Is COW ability of fork important enough with modern memory and operating systems, to maintain two significantly different code paths for spawning children processes? I looked at a stock 2.2 install (x86_64) with most modules built as DSOs, and it looks like there's about 1-2MB of anon heap allocated. (look at pmap or /proc/$PID/maps if anybody else wants to compare) So... I would guess the answer is, it depends, if that is a reasonable estimate at the fork benefit. If you expect people to be doing those insane 50K process tricks as are possible with prefork, then 50K*1MB is a huge additional overhead, yes. If not, then I'd guess it's lost in the noise. I think the far bigger difference between Windows and Unix on this front is fd/HANDLE inheritance though. Unless you want to get into passing fds over AF_UNIX sockets on Unix (please no) then there is going to remain a major disparity in how an MPM operates between the two platforms, and you might as well keep the stuff Unix does well, no? Regards, Joe
Re: Simple MPM is in trunk
On Thu, Oct 30, 2008 at 10:44 AM, Bing Swen [EMAIL PROTECTED] wrote: Jorge Schrauwen [EMAIL PROTECTED] wrote on 2008-10-30 17:03 On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen [EMAIL PROTECTED] wrote: Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; I have to admit it isn't easy to do so. But it certainly is possible! Due to lack of time on my part I've not updated the httpd wiki but you can find how to do it here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 First few times are the hardest but once you setup a nice build environment its all good. Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the best, although 2008 works too. If you can't be bothered with the trouble, there are unofficial binaries on there too if you want to play with it. 2. Many stock modules have no 64-bit configuration. Again it's a matter of recompiling, most windows users are spoiled and thing everything comes in nice binaries. libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for 64-bit, most are easier to do than httpd itself. Thanks for the nicely presented tutorial. I'll try to follow it and to understand what that 600+ PERL lines have fixed. So we have to get AWK, Bison, Flex and Sed to work, which are not required for a 32-bit build. And, we need a Perl Interpreter to run some magic conversions to get it built. That already made Win-x64 httpd a second-class citizen;) the perl file doesn't do it's job completely though, you still need a modified Makefile.win to fix some odd x64/release stuff that it wants in release. biggest problem atm is getting the apr dbd drivers for mysql and such. (never got that to work) 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. The improvement is httpd's virtual memory -- and actually very significant: we need to map a 500+ GB index into the memory space of httpd's child process. 64-bit space is our only choice;) Well a proxy with a mem_cache would definatly benifit from it. Bing
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
On Oct 29, 2008, at 5:04 PM, Graham Leggett wrote: Paul Querna wrote: FWIW, I don't believe in latest and greatest linux distro as a good measure, but I do believe that there are only a few platforms that we should make design decisions around: - Linux 2.6 - FreeBSD 7 - Solaris 10 - Windows Vista If something is *fast* or *good* and can be done on all of the above platforms, I would argue we should do it from a design perspective, and I'm very much opposed to limiting how we design stuff based on the constraints of other less popular operating systems, cf epoll/kqueue/event ports. I think we shouldn't forget that we have MPMs - if we need to support a non mainstream platform, at the very least make sure that at least one functional and acceptable alternative MPM exists for that platform. I tend to agree... as long as the architectural design doesn't prevent people from creating (or keeping) MPMs, then this is all good. Believe it or not, as people on the front-lines of handling Apache setup and support for organizations can attest to, MPMs are a valued feature.
Re: svn commit: r708935 - in /httpd/httpd/trunk: CHANGES modules/system/ modules/system/mod_unixd.c server/mpm/simple/simple_run.c
On Oct 29, 2008, at 4:12 PM, Ruediger Pluem wrote: On 10/29/2008 05:41 PM, [EMAIL PROTECTED] wrote: Author: niq Date: Wed Oct 29 09:41:10 2008 New Revision: 708935 URL: http://svn.apache.org/viewvc?rev=708935view=rev Log: Introduce modules/system, and mod_unixd.c mod_unixd.c is only os/unix/unixd.c, turned into a module. (or more accurately, an ugly hack). Work in progress, and the old unixd will have to go once the module build stuff is in place. This re-introduces some of the unixd stuff (set user, group and chroot) to mpm_simple, and should work equally well with existing MPMs. It also paves the way for alternative privilege management schemes, which can be implemented in alternative modules: this´ll be necessary to run mpm_simple on non-unix-family platforms, and of interest for alternative Unix implementations. By relegating everything to a child_init hook, we can mix-and-match, though weĺl need to add a regime that prevents just going right ahead with nothing and running as root. Round tuits permitting, we should be able to simplify unixd.h too, and look towards eliminating it. Just a remark. In all current MPM's ap_run_child_init runs with the root privileges already dropped. In the simple MPM this is now different in general (we are running with root priviledges here). But as mod_unixd registers an APR_HOOK_FIRST hook this will not make a difference for most modules as their child_init hooks are still run with the privileges already dropped. IMO, it should be APR_HOOK_REALLY_FIRST... There should never be any doubt or confusion where and when httpd drops privs. I can only imagine the can of worms
Re: MPMs, COW vs Child Process Spawning
On Oct 29, 2008, at 5:36 PM, Paul Querna wrote: Akins, Brian wrote: One of the things I've noticed on a practical level, is that forked children in worker wind up being linearized within themselves to some extent. Think of how the buffered logs work in mod_log_config (one buffer protected by a mutex). (I can't think of the correct term for it right now. Basically every thread is waiting on the same mutex eventually.) This is seen in other modules... The fork gets around this somewhat, as there are multiple mutexes independently locked/unlocked. I don't think the intention would be to use a single process on Unix -- we would still spawn multiple children -- they would just be created using fork+exec of the httpd binary, rather than just fork. Why? The most painful part is the actually forking, so why make it worse with tagging an exec with it? IMO, when Apache needs to fork (except for during startup), the assumption should be Because We Are Busy, and should be as efficient and quick as possible...
Re: AuthzMergeRules blocks everything in default configuration
Chris Darroch said the following on 10/29/2008 10:35 PM: Directory /humans_and_friendlies_only Require valid-user SatisfyNotAll Require group alien SatisfyAny Require group hostile Require group neutral Require group noninterventionist /SatisfyAny /SatisfyNotAll /Directory I wonder if we have to stick with building up complicated authorization expressions by nesting many different directives. I'd find it much easier to understand if we had fewer directives, and just built up the more complicated ideas by writing boolean expressions, which most of us already know how to cope with. I'm picturing something like this: Directory /humans_only AuthorizeIf valid-user AND member-of-group human /Directory Maybe with some syntactic sugar to help break things down into understandable chunks: DefineAuthorization friendly NOT (member-of-group hostile OR member-of-group neutral OR member-of-group noninterventionist) DefineAuthorization human NOT (member-of-group alien) Directory /humans_and_friendlies_only AuthorizeIf valid-user AND (human OR friendly) /Directory We could add a few more pre-defined primitives that could be used in expressions, such as # Inherit parent authorization, and add another condition AuthorizeIf authorized-in-parent AND member-of-group vips # Grant access to all AuthorizeIf true Granted, this is very different from the syntax in 2.2 configurations, so migration would have to be considered. But it might be worthwhile if something like this reduced confusion and questions on the lists. Dan
Re: Simple MPM is in trunk
Jorge Schrauwen wrote on 2008-10-30 18:46 biggest problem atm is getting the apr dbd drivers for mysql and such. (never got that to work) Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. The improvement is httpd's virtual memory -- and actually very significant: we need to map a 500+ GB index into the memory space of httpd's child process. 64-bit space is our only choice;) Well a proxy with a mem_cache would definatly benifit from it. apr dbd drivers have become a nightmare for those who tried and failed to build a Win-x64 httpd.exe after httpd-2.2.2. And we must have some source code integration with httpd itself (at least necessary for debugging), so we didn't use your unofficial binaries. It's been a shame (and frustration as well) to say that we are still using httpd-2.2.2 ... Bing
Re: Simple MPM is in trunk
On Oct 29, 2008, at 07:32, Joe Orton wrote: On Tue, Oct 28, 2008 at 12:12:51AM -0700, Paul Querna wrote: I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ Great! - The name. Someone suggest something better than Simple. I like naming projects by grepping the dictionary, and grepping for 'm.*p.*m' came up with wampum (amongst 1173 others ;), which is a North American Indian word, apparently - seems fitting. When I read this word, I hear bad actors saying lines like Me give-um you heap big wampum you not kill me! on 1950s Cowboys-and-Indians movies. Perhaps that association isn't there any more, but I think that every time we use a North American Indian word on one of our projects, we run the risk of going a little too far across the line of what is respectful of a much-abused subculture in the United States. -- If we only live, We too will go to sea in a Sieve,--- To the hills of the Chankly Bore!
Re: Memory leak in mod_proxy_http and in mpm_event components.
On 10/30/08 12:48 PM, Manik Taneja [EMAIL PROTECTED] wrote: So it seems that there is a slow-leak perhaps we might be hitting the problem that has been described in the following post. http://www.nabble.com/apr-pools---memory-leaks-td19766166.html FWIW, we always run with MaxRequestsPerChild set to something. Usually a fairly large number, but they recycle a few times a day or so. Start enough children, and we don't really notice a performance hit when the children are recycled. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Hi Devs and fellow list lurkers, I finally took the time to give this SNI business a try. I compiled the latest branch for the SVN with Kasper's patch on Windoze. After a hurdle with OpenSSL 098i that Tom Donovan was kind enough to help me jump over, I've got 2.2.11-dev with SNI working on Windows. Built with VC6. I've seen no word on anyone testing this on Windows so I thought I would chime in. I've been wanting this for longer than I can remember, 1.3.something. I've been following this testy at times thread but have gotten lost. I've seen the latest follow-up thread but am still uncertain as to any status at all. Has it been committed to Trunk which paves the way for a possible backport? Has any security implications (seem to remember one mentioned) been tamed? I'm still uncertain about IE7, I see Yes for Vista and No for XP but I've seen that statement contradicted. I (personally) have no problem forcing a visitor to use a compatible browser short of forcing them to Vista, but I'm not selling wares on my website either which would become more of a concern I imagine. At least I have it now and am not afraid to diff/patch/diff/patch my way along till either 2.4 rolls out or it is finally backported into Branch. Thanks Kasper for the patch Thanks Tom for your help as always. Thanks in advance to anyone that will nudge this ball further up the hill. Gregg Kaspar Brand wrote: That's the version I still consider suitable for check-in to trunk (attached again for convenience). A backport to 2.2.x is available at http://sni.velox.ch/httpd-2.2.x-sni.diff If, on the other hand, people think that SNI isn't important enough for 2.2.x, then I'd be glad to hear that as well (it doesn't make sense to repeatedly nag the list about that topic, I think). Kaspar
Re: Simple MPM is in trunk
On Oct 29, 2008, at 07:32, Joe Orton wrote: On Tue, Oct 28, 2008 at 12:12:51AM -0700, Paul Querna wrote: I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ Great! - The name. Someone suggest something better than Simple. I like naming projects by grepping the dictionary, and grepping for 'm.*p.*m' came up with wampum (amongst 1173 others ;), which is a North American Indian word, apparently - seems fitting. When I read this word, I hear bad actors saying lines like Me give-um you heap big wampum you not kill me! on 1950s Cowboys-and-Indians movies. Perhaps that association isn't there any more, but I think that every time we use a North American Indian word on one of our projects, we run the risk of going a little too far across the line of what is respectful of a much-abused subculture in the United States. -- If we only live, We too will go to sea in a Sieve,--- To the hills of the Chankly Bore!
Re: Broken trunk build
On Oct 29, 2008, at 6:21 AM, Nick Kew wrote: When svn up breaks a source file, at least you get a meaningful error message pointing to exactly what needs fixing. This m4 is nasty! If /usr/bin/m4 were by arbitrary fiat deleted from all unix-like systems world-wide, there would be considerable temporary breakage, but the world would on balance be a better place thereafter. -Tim
Re: MPMs, COW vs Child Process Spawning
On Oct 30, 2008, at 2:16 AM, Graham Leggett wrote: I don't think the intention would be to use a single process on Unix -- we would still spawn multiple children -- they would just be created using fork+exec of the httpd binary, rather than just fork. This doesn't make sense - fork is far more efficient than fork+exec, we shouldn't be supporting the less efficient one for everybody just because it means less code. Instead we should try and fork, and if fork fails (eg Windows), or where configured (eg Leopard until Apple fixes it), it should fall back gracefully to fork+exec. +1 I'd think that most people who'd done process-wrangling in unix-like systems and other alternatives (VMS, Windows) would have come to appreciate the many virtues of fork(). This feels like a pessimization. -T
Re: Broken trunk build
On Oct 30, 2008, at 3:00 PM, Tim Bray wrote: On Oct 29, 2008, at 6:21 AM, Nick Kew wrote: When svn up breaks a source file, at least you get a meaningful error message pointing to exactly what needs fixing. This m4 is nasty! If /usr/bin/m4 were by arbitrary fiat deleted from all unix-like systems world-wide, there would be considerable temporary breakage, but the world would on balance be a better place thereafter. -Tim Still semi-broken if trying the simple MPM due to both mod_unixd and unixd being built: ld: duplicate symbol _unixd_set_user in os/unix/.libs/libos.a(unixd.o) and modules/arch/unix/.libs/libmod_unixd.a(mod_unixd.o) collect2: ld returned 1 exit status Plus, we need to get a mod_unixd.h file which exports those functions... currently have a *nasty* cruft just to get the bugger compiled to play around with it :)
Re: Broken trunk build
Tim Bray wrote: On Oct 29, 2008, at 6:21 AM, Nick Kew wrote: When svn up breaks a source file, at least you get a meaningful error message pointing to exactly what needs fixing. This m4 is nasty! If /usr/bin/m4 were by arbitrary fiat deleted from all unix-like systems world-wide, there would be considerable temporary breakage, but the world would on balance be a better place thereafter. -Tim scons. -Paul
Re: Broken trunk build
Jim Jagielski wrote: On Oct 30, 2008, at 3:00 PM, Tim Bray wrote: On Oct 29, 2008, at 6:21 AM, Nick Kew wrote: When svn up breaks a source file, at least you get a meaningful error message pointing to exactly what needs fixing. This m4 is nasty! If /usr/bin/m4 were by arbitrary fiat deleted from all unix-like systems world-wide, there would be considerable temporary breakage, but the world would on balance be a better place thereafter. -Tim Still semi-broken if trying the simple MPM due to both mod_unixd and unixd being built: ld: duplicate symbol _unixd_set_user in os/unix/.libs/libos.a(unixd.o) and modules/arch/unix/.libs/libmod_unixd.a(mod_unixd.o) collect2: ld returned 1 exit status Plus, we need to get a mod_unixd.h file which exports those functions... currently have a *nasty* cruft just to get the bugger compiled to play around with it :) no, mod_unixd should not need to export any functions like current unixd does I'll rename them so there aren't any symbol conflicts, but they should all be static anyways inside mod_unixd.c. -Paul
Re: [ANNOUNCEMENT] Apache HTTP Server 2.2.10 Released
Jim, It might be too late to do anything, but it doesn't seem that this announcement email went to [EMAIL PROTECTED] or to [EMAIL PROTECTED] did they get suck in moderation? Thanks, Paul Jim Jagielski wrote: Apache HTTP Server 2.2.10 Released The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.2.10 of the Apache HTTP Server (Apache). This version of Apache is principally a bug and security fix release. The following potential security flaws are addressed: * CVE-2008-2939 (cve.mitre.org) mod_proxy_ftp: Prevent XSS attacks when using wildcards in the path of the FTP URL. Discovered by Marc Bevand of Rapid7. We consider this release to be the best version of Apache available, and encourage users of all prior versions to upgrade. Apache HTTP Server 2.2.10 is available for download from: http://httpd.apache.org/download.cgi Apache 2.2 offers numerous enhancements, improvements, and performance boosts over the 2.0 codebase. For an overview of new features introduced since 2.0 please see: http://httpd.apache.org/docs/2.2/new_features_2_2.html Please see the CHANGES_2.2 file, linked from the download page, for a full list of changes. A condensed list, CHANGES_2.2.10 provides the complete list of changes since 2.2.9. A summary of security vulnerabilities which were addressed in the previous 2.2.9 and earlier releases is available: http://httpd.apache.org/security/vulnerabilities_22.html Apache HTTP Server 1.3.41 and 2.0.63 legacy releases are also currently available. See the appropriate CHANGES from the url above. See the corresponding CHANGES files linked from the download page. The Apache HTTP Project developers strongly encourage all users to migrate to Apache 2.2, as only limited maintenance is performed on these legacy versions. This release includes the Apache Portable Runtime (APR) version 1.3.0 bundled with the tar and zip distributions. The APR libraries libapr and libaprutil (and on Win32, libapriconv) must all be updated to ensure binary compatibility and address many known platform bugs. This release builds on and extends the Apache 2.0 API. Modules written for Apache 2.0 will need to be recompiled in order to run with Apache 2.2, and require minimal or no source code changes. http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/VERSIONING When upgrading or installing this version of Apache, please bear in mind that if you intend to use Apache with one of the threaded MPMs (other than the Prefork MPM), you must ensure that any modules you will be using (and the libraries they depend on) are thread-safe.
Re: Broken trunk build
On Oct 30, 2008, at 4:19 PM, Paul Querna wrote: Jim Jagielski wrote: On Oct 30, 2008, at 3:00 PM, Tim Bray wrote: On Oct 29, 2008, at 6:21 AM, Nick Kew wrote: When svn up breaks a source file, at least you get a meaningful error message pointing to exactly what needs fixing. This m4 is nasty! If /usr/bin/m4 were by arbitrary fiat deleted from all unix-like systems world-wide, there would be considerable temporary breakage, but the world would on balance be a better place thereafter. -Tim Still semi-broken if trying the simple MPM due to both mod_unixd and unixd being built: ld: duplicate symbol _unixd_set_user in os/unix/.libs/ libos.a(unixd.o) and modules/arch/unix/.libs/ libmod_unixd.a(mod_unixd.o) collect2: ld returned 1 exit status Plus, we need to get a mod_unixd.h file which exports those functions... currently have a *nasty* cruft just to get the bugger compiled to play around with it :) no, mod_unixd should not need to export any functions like current unixd does Hmmm... must have misunderstood the intent of the module... Looking into it, and rereading Nick's email, I got it now. I'll rename them so there aren't any symbol conflicts, but they should all be static anyways inside mod_unixd.c. +1
Re: [ANNOUNCEMENT] Apache HTTP Server 2.2.10 Released
Paul Querna wrote: Jim, It might be too late to do anything, but it doesn't seem that this announcement email went to [EMAIL PROTECTED] or to [EMAIL PROTECTED] I didn't see the moderation message for [EMAIL PROTECTED]
Re: Broken trunk build
Jim Jagielski wrote: Still semi-broken if trying the simple MPM due to both mod_unixd and unixd being built: I presume this isn't about simple mpm - that mod_unixd is going to be modularized for all unix mpm's?
Re: [ANNOUNCEMENT] Apache HTTP Server 2.2.10 Released
Tony Stevenson wrote: Paul Querna wrote: Jim, It might be too late to do anything, but it doesn't seem that this announcement email went to [EMAIL PROTECTED] or to [EMAIL PROTECTED] I didn't see the moderation message for [EMAIL PROTECTED] You wouldn't have. Sent from jaguNET.com... Jim would you care to resend from @apache.org, pls?
Re: Broken trunk build
William A. Rowe, Jr. wrote: Jim Jagielski wrote: Still semi-broken if trying the simple MPM due to both mod_unixd and unixd being built: I presume this isn't about simple mpm - that mod_unixd is going to be modularized for all unix mpm's? That's the idea, yes. Plus a decision over whether everything goes into the module, or some stuff remains in the old unixd. Just about to look at Paul's update to that. Simple MPM was just a good cue to actually do something. When simple told me the User directive in httpd.conf was unrecognised -- Nick Kew
