UNIX MPMs

2005-02-10 Thread Nick Maynard
. In addition, special features like serving different hosts under different userids (perchild) can be provided. This is all very well, but none of the special features work, and have not worked for at least a year. This is the status of MPMs for UNIX at the moment: UNIX MPMs in Apache 2

Re: UNIX MPMs

2005-02-10 Thread Nick Kew
for switching to Apache 2. Really? The old MPM isn't *that* bad for most applications. Except on those non-unix-like platforms where forking is stupidly inefficient. UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) + event (new - hopefully) But the main thing MPMs have

Re: UNIX MPMs

2005-02-10 Thread Nick Maynard
Apologies to all if this sounds a little harsh, but I've been banging my head against the perchild problem, and associated workarounds for a lack of it, for so long it seems my entire Apache config life is taken up with it. I'd just like some kind of indication of whether it will ever get

Re: UNIX MPMs

2005-02-10 Thread Mads Toftum
On Thu, Feb 10, 2005 at 01:16:10PM +, Nick Maynard wrote: If not, you/we really should tell everyone, and let it die its natural death. Maybe I've missed you doing this, but your docs do say work is ongoing on perchild... The docs have been updated (all complete and in a red warning

Re: UNIX MPMs

2005-02-10 Thread Paul A. Houle
On Thu, 10 Feb 2005 11:56:47 +, Nick Maynard [EMAIL PROTECTED] wrote: UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) Yeah, but what if you want to run PHP or mod_perl? Sure, PHP or mod_perl ~might~ work for you if you're lucky and you don't

Re: UNIX MPMs

2005-02-10 Thread Jim Jagielski
Paul A. Houle wrote: On Thu, 10 Feb 2005 11:56:47 +, Nick Maynard [EMAIL PROTECTED] wrote: UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) Yeah, but what if you want to run PHP or mod_perl? Sure, PHP or mod_perl ~might~ work

Re: UNIX MPMs [ot?]

2005-02-10 Thread Leif W
Nick Kew [EMAIL PROTECTED]; [EMAIL PROTECTED]:11 GMT-5 I agree the documentation should be better. Also we should properly document the perchild-like options, since that is frequently-requested. In the meantime, here's a list of things to look at if you want perchild-like: * Metux MPM *

Re: UNIX MPMs [ot?]

2005-02-10 Thread Nick Kew
On Thursday 10 February 2005 14:10, Leif W wrote: Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of Apache 2.0.x with all file i/o and cgi being done by a

Re: UNIX MPMs

2005-02-10 Thread William A. Rowe, Jr.
At 07:24 AM 2/10/2005, Paul A. Houle wrote: On Thu, 10 Feb 2005 11:56:47 +, Nick Maynard [EMAIL PROTECTED] wrote: UNIX MPMs that actually _work_ in Apache 2: worker Yeah, but what if you want to run PHP or mod_perl? Sure, PHP or mod_perl ~might~ work for you

RE: UNIX MPMs [ot?]

2005-02-10 Thread Sander Striker
From: Leif W [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 3:10 PM [...] It's already a huge list of workaround and compatibility and portability for an admin could be a nightmare. I do not know if there are even more security wrappers needed for other language modules. Can

Re: UNIX MPMs [ot?]

2005-02-10 Thread William A. Rowe, Jr.
At 08:10 AM 2/10/2005, Leif W wrote: I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. The strength of Apache was always *nix,

Re: UNIX MPMs

2005-02-10 Thread Graham Leggett
On Thursday 10 February 2005 11:56, Nick Maynard wrote: OK - let's face it. Most people who seriously run Apache (1.3/2) run it on a UNIX system. Often Linux. Some people have switched from Apache 1.3 to Apache 2 for a variety of reasons, but from my POV the new MPMs were the primary

Re: UNIX MPMs

2005-02-10 Thread Nick Maynard
The docs have been updated (all complete and in a red warning box): http://httpd.apache.org/docs-2.0/mod/perchild.html This module is not functional. Development of this module is not complete and is not currently active. Do not use perchild unless you are a programmer willing to help fix it.

Re: UNIX MPMs [ot?]

2005-02-10 Thread Leif W
Nick Kew [EMAIL PROTECTED]; [EMAIL PROTECTED]:15 GMT-5 On Thursday 10 February 2005 14:10, Leif W wrote: Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of

Re: UNIX MPMs

2005-02-10 Thread Greg Ames
Nick Maynard wrote: UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) event (experimental) unclear if it works with mod_ssl with pipelining (not tested here yet) Greg

Re: UNIX MPMs

2005-02-10 Thread Greg Ames
Paul A. Houle wrote: On Linux I've done some benchmarking and found that worker isn't any faster than prefork at serving static pages. (Is it any different on other platforms, such as Solaris?) I'm sure we can tweak worker and event to make them faster, especially in 2.1+ with

Re: UNIX MPMs

2005-02-10 Thread Rasmus Lerdorf
Paul A. Houle wrote: On Linux I've done some benchmarking and found that worker isn't any faster than prefork at serving static pages. (Is it any different on other platforms, such as Solaris?) In principle you might save RAM by running prefork, but in this day and age you can fit 16

Re: UNIX MPMs [ot?]

2005-02-10 Thread Leif W
Sander Striker [EMAIL PROTECTED]; [EMAIL PROTECTED]:35 GMT-5 From: Leif W [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 3:10 PM things which might commonly be used in concert? Is there any direction given from the top of the Apache group in regards to what gets attention? No, there

Re: UNIX MPMs [ot?]

2005-02-10 Thread Jim Jagielski
Leif W wrote: My only concern is, if some people solved the puzzle externally, then are there barriers which prevent them from getting the code committed? The Metux web pages (official and unofficial) seem to be works in progress. There is a quote which indicates that at least the guy

Re: UNIX MPMs

2005-02-10 Thread Andy Armstrong
On 10 Feb 2005, at 16:45, Rasmus Lerdorf wrote: If you know of such a programmer that can quickly identify and fix race conditions, please send him my way. I will give him a job in a second. It kind of depends how well the races are hidden, doesn't it? :) -- Andy Armstrong, hexten.net

un-macho serviceability aid for Unix MPMs

2004-03-03 Thread Jeff Trawick
). If there is positive encouragement, I'll commit to 2.1-dev, but I'd move the check_dumpable() function to ap_check_dumpable() in mpm_common.c and call it from all the Unix MPMs. The current patch is worker-specific. If there is interest in the patch for 1.3, let me know and I'll post. It is a bit

Re: un-macho serviceability aid for Unix MPMs

2004-03-03 Thread Joe Orton
On Wed, Mar 03, 2004 at 06:34:06AM -0500, Jeff Trawick wrote: This checks for a couple of common conditions which prevent core dumps from being taken and writes a NOTICE message to the error log at startup if the condition is detected. BTW, the same code works with 1.3 with very minor

Re: un-macho serviceability aid for Unix MPMs

2004-03-03 Thread Jeff Trawick
Joe Orton wrote: On Wed, Mar 03, 2004 at 06:34:06AM -0500, Jeff Trawick wrote: This checks for a couple of common conditions which prevent core dumps from being taken and writes a NOTICE message to the error log at startup if the condition is detected. BTW, the same code works with 1.3 with

Re: un-macho serviceability aid for Unix MPMs

2004-03-03 Thread Justin Erenkrantz
--On Wednesday, March 3, 2004 7:26 AM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: I can go either way on whether or not we attempt to raise the soft limit to a *non-zero* hard limit when CoreDumpDirectory is specified. Any other opinions? Raising to the hard limit seems perfectly reasonable. --

Re: un-macho serviceability aid for Unix MPMs

2004-03-03 Thread Paul J. Reder
Jeff Trawick wrote: Joe Orton wrote: On Wed, Mar 03, 2004 at 06:34:06AM -0500, Jeff Trawick wrote: This checks for a couple of common conditions which prevent core dumps from being taken and writes a NOTICE message to the error log at startup if the condition is detected. BTW, the same code