UNIX MPMs
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 reason for switching to Apache 2. This is an excerpt from the MPM blurb on the main doc pages: The server can be better customized for the needs of the particular site. For example, sites that need a great deal of scalability can choose to use a threaded MPM like worker, while sites requiring stability or compatibility with older software can use a prefork. 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: perchild worker threadpool (experimental) leader (experimental) prefork (old) UNIX MPMs that actually _work_ in Apache 2: worker prefork (old) Let me focus on perchild (an MPM that should work) for a moment. * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me how the Perchild MPM should be re-written. It hasn't worked correctly since filters were added because it wasn't possible to get the content that had already been written and the socket at the same time. This mode lets us do that, so the MPM can be fixed. The STATUS documents have included the above statement for (over?) a year now. A few months after it appeared the perchild MPM docs were updated to say the equivalent of sorry, we broke it. It seems there's lots of information about how wonderful the UNIX Apache 2 MPMs are, but little actual substance. In this all-singing, all-dancing not-so-new implementation of the world's most popular web server, we have - count 'em - ONE new MPM for UNIX that works. So - could someone who understands these things comment on whether there is any commitment to fix perchild, or any of the other UNIX Apache 2 MPMs at some point? Failing that, maybe the documentation for Apache 2 could be updated to avoid giving people the wrong impression from the outset. Thanks, Nick Maynard [EMAIL PROTECTED]
Re: UNIX MPMs
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 reason 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 done is make Apache truly cross-platform, rather than a Unix server that can be made to work (rather badly) on other platforms. Let me focus on perchild (an MPM that should work) for a moment. * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me how the Perchild MPM should be re-written. It hasn't worked correctly since filters were added because it wasn't possible to get the content that had already been written and the socket at the same time. This mode lets us do that, so the MPM can be fixed. The STATUS documents have included the above statement for (over?) a year now. A few months after it appeared the perchild MPM docs were updated to say the equivalent of sorry, we broke it. Noone is working on it. Feel free to commission some work, or take up the task yourself. So - could someone who understands these things comment on whether there is any commitment to fix perchild, or any of the other UNIX Apache 2 MPMs at some point? Failing that, maybe the documentation for Apache 2 could be updated to avoid giving people the wrong impression from the outset. 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 * mod_ruid (Linux only) * fastcgi (CGI plus) * suexec (for CGI) I don't know enough about them or your needs to advise you. -- Nick Kew
Re: UNIX MPMs
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 fixed. 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... Thanks, Nick Maynard [EMAIL PROTECTED]
Re: UNIX MPMs
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 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. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: UNIX MPMs
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 compile in the wrong third-party library, but you'll be in a world of pain if you don't. It's very hard to bolt threading onto an existing system that links to legacy libraries. Java managed to provide a thread-safe environment by having a painful API to link to C code, 100% Pure Java xenophobia -- and it still took them 5 years to make a JVM which was reliable enough for government work. 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 GB in a 1U pretty easily and it's cheaper than hiring a programmer who doesn't know how to track down race conditions, never mind one that does.
Re: UNIX MPMs
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 for you if you're lucky and you don't compile in the wrong third-party library, but you'll be in a world of pain if you don't. Use prefork. No threads. 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?) Yes, there is little differences under Linux, but substantial ones under other OSs such as AIX, Solaris, HP-UX... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: UNIX MPMs [ot?]
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 * mod_ruid (Linux only) * fastcgi (CGI plus) * suexec (for CGI) 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 single user, and the perchild MPM being broken. The frustration is that it is difficult, if not impossible (and potentially not even portable) to get all of these workarounds working together. And the clinching belief is that these should all be handled in the core of Apache, or with a working MPM. Here I post as complete a list I can think of including the new ones I see above. * cgiwrap * FastCGI * Metux MPM * mod_perl * mod_php * mod_ruid (Linux only) * suexec * suphp 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 anyone add to the list some 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? In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority (at least regarding setuid per request as perchild MPM would like to do), only competing with MS/IIS. I'm not implying anything, I don't know what to believe, so that's why I ask. 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, so why abandon security on *nix for the sake of portability to Windows? It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, and other people just happened to want to increase portability to windows? I mean, I like having a windows port, because I can at least practice using Apache somewhat, and it expands the development platform, but I won't ever, ever, EVER run it on Windows in production, simply because I'd never run Windows in production. Except insofar as to show Windows users a shining example of free software, and offer the idea of using an entire OS filled with shining examples of free software engineering. ;-) Toungue in cheek of course, with the ugly little problems such as this code abandonment of vital features at the back of my mind. I don't mean to start an OS flame war, so please don't respond with that in mind. :-) If other people would like to use Windows, it takes nothing away from me, I'm just stating opinion based on my own interaction and experience with Apache, Win, and *nix (Linux FreeBSD). Leif
Re: UNIX MPMs [ot?]
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 single user, and the perchild MPM being broken. That's rather different. If you care *at all* about security, you won't be running PHP as a module. So suexec is a complete solution there. -- Nick Kew
Re: UNIX MPMs
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 if you're lucky and you don't compile in the wrong third-party library, but you'll be in a world of pain if you don't. So true ... while you are at it, watch out for those libraries with Y2K bugs. Oh, and 2038 bugs if you last that long. Sorry, but get used to this stock response to 'threads are dangerous' trolls for the next 32 years :)
RE: UNIX MPMs [ot?]
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 anyone add to the list some 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 is not. The committers are free to work on what they want. In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. only competing with MS/IIS. Not even that. I mean, it's fun to watch our marketshare rise every month, but that's not what the ASF is all about. I'm not implying anything, I don't know what to believe, so that's why I ask. 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. Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? There's more to it than just portability to Windows. It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, Correct. and other people just happened to want to increase portability to windows? Portability in general. But this is all contained in the APR project, on top of which httpd-2.x is built. Also people worked on a lot of other things during last year. Just look at the Changelog, the commit messages etc, to see what I mean. I mean, I like having a windows port, because I can at least practice using Apache somewhat, and it expands the development platform, but I won't ever, ever, EVER run it on Windows in production, simply because I'd never run Windows in production. Not all administrators are in a position where they can refuse to run Windows. Except insofar as to show Windows users a shining example of free software, and offer the idea of using an entire OS filled with shining examples of free software engineering. ;-) Toungue in cheek of course, with the ugly little problems such as this code abandonment of vital features at the back of my mind. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. I don't mean to start an OS flame war, so please don't respond with that in mind. :-) If other people would like to use Windows, it takes nothing away from me, I'm just stating opinion based on my own interaction and experience with Apache, Win, and *nix (Linux FreeBSD). The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Sander
Re: UNIX MPMs [ot?]
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, so why abandon security on *nix for the sake of portability to Windows? What gives you the impression that this has anything to do with alternate ports? What gives you the impression that Apache 1.3 had this right? You hit the nail on the head A feature that people want ... ... but apparently not badly enough to solve the puzzle? The Apache Software Foundation puts together code that folks want to create, it doesn't put together code that folks want to have created for them. Rather than bemoan the fact that something doesn't exist/is broken/isn't complete enough, they are welcome in any ASF project to offer issue + solution to their own itch. At least, when that solution in in the form of ASF Licensed code. It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, and other people just happened to want to increase portability to windows? Ding ding ding. Each developer has their own expertise(s) and scratches their own itch. There is no ombudsman who is saying Oh, you can add that code, just as soon as you go mop up this code over here... If you are suggesting that OtherBill should be fixing Perchild to support Linux users and not off supporting Win32 users, well then, bite me :) Perchild will be fixed the moment someone wants to invest the time to fix perchild. There is no obstacle, there is also no volunteer. And several folks out there, rather than fix Perchild, have set out to do their own thing instead to create such features. Nothing stopping them from offering their own solution out there, nothing stopping them from contributing here. And so it is as it should be.
Re: UNIX MPMs
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 reason for switching to Apache 2. I don't think this is true. The primary audience for MPMs is the developers rather than end users: Now the Windows port of httpd can now be Windows specific, rather than be buggy code full of #ifdefs. From an end user perspective it means that the code is more reliable, but at the end of the day a platform will probably have a preferred MPM, unless the user has special needs. MPMs are something most users will not need to worry about. If there is just one MPM for a platform, even if that platform is Unix in general, that's fine as long as that MPM works. If a second MPM comes along and is better, then so be it. If an MPM exists as an experiment, but ends up abandoned because another MPM is better, this isn't a problem. The only requirement is that there is at least one MPM for a platform, and it works. My primary reasons for switching to v2.0 and then v2.1 (as a webmaster) were filters and the caching code. Regards, Graham --
Re: UNIX MPMs
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. Hello Mads, That's fantastic. Could the docs at http://httpd.apache.org/docs-2.0/mpm.html be updated to reflect this too? Thanks, Nick Maynard [EMAIL PROTECTED]
Re: UNIX MPMs [ot?]
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 Apache 2.0.x with all file i/o and cgi being done by a single user, and the perchild MPM being broken. That's rather different. If you care *at all* about security, you won't be running PHP as a module. So suexec is a complete solution there. Does this idea extend to any other modules as well? Are they all insecure simply because of Apache's design? Is that where the security problem lies? The module code can not be run as a separate user with fewer privileges per request? Leif
Re: UNIX MPMs
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
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 judicious use of the improved apr atomics. But for now I think it's more important to deal with thread safety in the modules and libraries. In principle you might save RAM by running prefork, I assume you mean worker. some of my customers have reported dramatic RAM savings with worker. but in this day and age you can fit 16 GB in a 1U pretty easily and it's cheaper than hiring a programmer who doesn't know how to track down race conditions, never mind one that does. sure, but if you are using modules + libraries that are know to be thread safe, life is good. Greg
Re: UNIX MPMs
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 GB in a 1U pretty easily and it's cheaper than hiring a programmer who doesn't know how to track down race conditions, never mind one that does. 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. -Rasmus
Re: UNIX MPMs [ot?]
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 is not. The committers are free to work on what they want. Ok, just wasn't sure how the ASF worked, some combination of directed and volunteer effort or something. Not do this or else strict direction, but please focus energy here if you can, a laidback direction. In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. That's quoted out of context. Security holes get prompt attention. I was referring specifically to security as presented by perchild, as noted in the parenthisized expression below which was part of the same sentence. Sorry if my wording misconstrued the point. (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. [...] Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. I'd be more than happy to scratch this itch, but I haven't the coding ability or speed, testing environment, resources or time right now. I'd do it for the fee of training me how to do it. :p I'll need to consult the reference manuals. If I had financial resources I'd use them to encourage itches like this to be scratched, because when admin get burnt out over a missing feature, I'd like to give back that enthusiasm and fun and peace of mind. Coding is hard work and people deserve something for the time, even if enjoyment of the coding effort is usually enough. FWIW, I try to payback to this specific in the only way I can, by helping on the users list, and occasionally try to submit simpler code to other projects. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. There may be a discrepancy between what developers in general consensus think is vital, what is vital to individual developers, what admin think is vital, or people of different platforms, or what combinations of technologies are being used in concert. I'm thinking vital in terms of a common problem which many experience, for whom various workarounds do not work that well. To that end I am just curious about what it takes to have something of that magnitude eventually committed. If no developers are currently interested in a topic, who reviews it? What if someone applies to be a developer and says this is vital to them and a portion of the user base? Wether RTC or CTR, some patches of a lesser magnitude (affecting only one module for instance) seem to fly right through, yet other patches hang around a long time. I am just curious if status quo vs. who you know plays any part in the process. If so then it has to be planned for and addressed by anyone attempting to make a contribution. I'm not so good figuring this stuff out, so that's why I ask. The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Hmm, sorry, I didn't even see that happening. I did not feel like I was requesting a discussion of the A vs. B, but it maybe opened the wrong door, and I'm sorry for that. I mentioned something about A and B, thought that it might be mistaken for an argument of pro A con B, and stated that I didn't wish to discuss it in that context, and hoped that would be enough. The initial discussion was presented to me as perchild mpm (security) vs winnt mpm (portability), so my initial thoughts were along that line. But as I indicated, I considered the possibility that it was just a coincidence of events, not a directed intent. If I say I prefer A to B, is that wrong? IMO no, because I did not ask anyone to agree, nor ask their opinion, nor tell anyone what to prefer. You don't have to talk about that then. :-) I am not arguing for or against an OS. I just mentioned the three as the OSes to which I have had access, and experience, and to which platform some 3rd party solutions to setuid/setgid (perorphan?) are available and some are not. Of course I'd like a portable
Re: UNIX MPMs [ot?]
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 running the unofficial site would like to see this in Apache some day. The ASF doesn't suffer from the not coded here mentality. Many of our successful projects and codebases have originally started life elsewhere. As far as I know, even though internal (to the ASF) development of perchild languished, we did accept patches, etc. So if anyone had wanted to continue working on it, they could have done what countless other developers have done and submitted patches, etc... That's the start towards getting ASF commit privs, becoming a contributor, a PMC member and an ASF member. If Metux would like to donate the code to the ASF, then incubator.apache.org would be a good link to check out first. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: UNIX MPMs
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
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
tweaks (remove the apr_status_t parm from ap_log_error IIRC).
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 motherly, but it can be a general educational tool for users and it
also provides some appropriate negative feedback if the user is wondering why
coredumps are not being written.
Index: server/mpm/worker/worker.c
===
RCS file: /cvs/phoenix/2.0.47/server/mpm/worker/worker.c,v
retrieving revision 1.5
diff -u -r1.5 worker.c
--- server/mpm/worker/worker.c 13 Feb 2004 16:56:27 - 1.5
+++ server/mpm/worker/worker.c 3 Mar 2004 10:37:03 -
@@ -1671,6 +1671,52 @@
}
}
+/* IHS addition */
+static void check_dumpable(server_rec *s)
+{
+struct rlimit rl;
+int rc;
+int already_complained = 0;
+
+rc = getrlimit(RLIMIT_CORE, rl);
+if (rc == 0) {
+if (rl.rlim_cur == 0) { /* if it worked */
+/* Regardless of whether or not the server was started as root,
+ * a soft limit of zero for core file size prevents core dumps
+ * from being written for any web server processes.
+ * Theoretically we could try to raise the soft limit to the
+ * hard limit (if it is higher), but perhaps this is the
+ * administrator's way to say they want no core dumps.
+ */
+ap_log_error(APLOG_MARK, APLOG_NOTICE,
+ 0,
+ s,
+ Core file limit is 0; core dumps will be not be
+ written for server crashes);
+already_complained = 1;
+}
+}
+
+if (!already_complained
+geteuid() == 0
+!ap_coredumpdir_configured) {
+/* The server has started as root, so child processes run as another
+ * user. They SHOULD NOT have permission to write to the web server
+ * install directory, so if CoreDumpDirectory hasn't been specified,
+ * then in general no core dump can be written.
+ * Exception: On Solaris, the coreadm command can be used to specify
+ * an alternate directory for core dumps to be written.
+ * Potentially the same feature is/will be available on other platforms.
+ */
+ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE,
+ 0,
+ s,
+ CoreDumpDirectory not set; core dumps may not be written for
+ child process crashes);
+}
+}
+/* end IHS addition */
+
int ap_mpm_run(apr_pool_t *_pconf, apr_pool_t *plog, server_rec *s)
{
int remaining_children_to_start;
@@ -1763,6 +1809,10 @@
apr_proc_mutex_name(accept_mutex),
apr_proc_mutex_defname());
#endif
+/* IHS addition */
+check_dumpable(ap_server_conf);
+/* end IHS addition */
+
restart_pending = shutdown_pending = 0;
server_main_loop(remaining_children_to_start);
Re: un-macho serviceability aid for Unix MPMs
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
tweaks (remove the apr_status_t parm from ap_log_error IIRC).
I wrote a patch for a essentially the same feature recently: the common
case is where the soft limit is set to zero but the hard limit is not;
so iff CoreDumpDirectory is used, just raise the soft limit to the hard
limit.
--- httpd-2.0.48/server/core.c.corelimit
+++ httpd-2.0.48/server/core.c
@@ -4233,6 +4233,25 @@
ap_set_version(pconf);
ap_setup_make_content_type(pconf);
+
+#ifdef RLIMIT_CORE
+if (ap_coredumpdir_configured) {
+struct rlimit lim;
+
+if (getrlimit(RLIMIT_CORE, lim) == 0 lim.rlim_cur == 0) {
+lim.rlim_cur = lim.rlim_max;
+if (setrlimit(RLIMIT_CORE, lim) == 0) {
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, NULL,
+ core dump file size limit raised to %lu bytes,
+ lim.rlim_cur);
+} else {
+ap_log_error(APLOG_MARK, APLOG_NOTICE, errno, NULL,
+ core dump file size is zero, setrlimit failed);
+}
+}
+}
+#endif
+
return OK;
}
Re: un-macho serviceability aid for Unix MPMs
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 very minor
tweaks (remove the apr_status_t parm from ap_log_error IIRC).
I wrote a patch for a essentially the same feature recently: the common
case is where the soft limit is set to zero but the hard limit is not;
so iff CoreDumpDirectory is used, just raise the soft limit to the hard
limit.
I was scared to raise the soft limit on core files, but I forgot about the
presumed sanity of doing it if ap_coredumpdir_configured is set (just like
prctl()).
+if (getrlimit(RLIMIT_CORE, lim) == 0 lim.rlim_cur == 0) {
+lim.rlim_cur = lim.rlim_max;
+if (setrlimit(RLIMIT_CORE, lim) == 0) {
In your patch, if the hard limit for core files is zero, there won't be a
message, will there?
An odd case is Solaris where CoreDumpDirectory is not ordinarily necessary if
coreadm is used to set the full path of core files. In my patch the user would
get a warning if ulimit is going to prohibit getting a core dump.
Another case where CoreDumpDirectory is not ordinarily necessary is when the
server is started as non-root. Yet it is still a problem if the core limit is
zero.
I definitely prefer always reporting a missing CoreDumpDirectory if the server
started as root.
I definitely prefer always reporting when the core limit is zero, root or not.
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?
Re: un-macho serviceability aid for Unix MPMs
--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. -- justin
Re: un-macho serviceability aid for Unix MPMs
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 works
with 1.3 with very minor tweaks (remove the apr_status_t parm from
ap_log_error IIRC).
I wrote a patch for a essentially the same feature recently: the common
case is where the soft limit is set to zero but the hard limit is not;
so iff CoreDumpDirectory is used, just raise the soft limit to the hard
limit.
I was scared to raise the soft limit on core files, but I forgot about
the presumed sanity of doing it if ap_coredumpdir_configured is set
(just like prctl()).
+if (getrlimit(RLIMIT_CORE, lim) == 0 lim.rlim_cur == 0) {
+lim.rlim_cur = lim.rlim_max;
+if (setrlimit(RLIMIT_CORE, lim) == 0) {
In your patch, if the hard limit for core files is zero, there won't be
a message, will there?
An odd case is Solaris where CoreDumpDirectory is not ordinarily
necessary if coreadm is used to set the full path of core files. In my
patch the user would get a warning if ulimit is going to prohibit
getting a core dump.
Another case where CoreDumpDirectory is not ordinarily necessary is when
the server is started as non-root. Yet it is still a problem if the
core limit is zero.
I definitely prefer always reporting a missing CoreDumpDirectory if the
server started as root.
I definitely prefer always reporting when the core limit is zero, root
or not.
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?
I would be inclined to raise the soft limit if CoreDumpDirectory is set and
log a message that it had been done. I'm a big believer in letting the user know
if you automagically do something for them. The log entry would let them know
that they need to remove CoreDumpDirectory if they don't want this.
I would also be inclined to log a message if core limit is zero, root or not,
so that we have predictable behavior (regardless of the platform). It would add
a level of uncertainty if it didn't since we would have to ask, Is this Solaris
(or some other system with similar behavior) and is there a value set in coreadm
for core files?
So I guess I'd recommend something like:
static void check_dumpable(server_rec *s)
{
struct rlimit rl;
int rc;
int already_complained = 0;
rc = getrlimit(RLIMIT_CORE, rl);
if (rc == 0) {
if (ap_coredumpdir_configured) {
if ((rl.rlim_cur == 0) (rl.rlim_max 0)) {
rl.rlim_cur = rl.rlim_max;
ap_log_error (APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
Soft limit for core files raised to hard limit of (%d)
since CoreDumpDirectory is set.,
rl.rlim_max);
}
else if (rl.rlim_max == 0) {
ap_log_error (APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
Despite the user specified CoreDumpDirectory value,
core files cannot be created since hard limit is 0.);
}
/* Do we want to be *really* motherly? */
else if ((rl.rlim_cur 0) (rl.rlim_max 0)) {
ap_log_error (APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
Potential core files to be stored at %s,
ap_coredump_dir);
}
}
else {
if (rl.rlim_max == 0) {
ap_log_error (APLOG_MARK, APLOG_NOTICE, 0, s,
Core files cannot be created since hard limit is 0.);
}
else if (geteuid() == 0) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
CoreDumpDirectory not set; core dumps may not be written
for
child process crashes);
}
}
}
}
--
Paul J. Reder
---
The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure.
-- Albert Einstein
