ExtendedStatus On as core directive in trunk?
It is currently necessary to load/protect mod_status so that some other module can use the extended status information in the scoreboard. mod_status is by far the most common use of the extended status. The comment in mod_status explains the reason why it is a mod_status directive: /* * command-related code. This is here to prevent use of ExtendedStatus * without status_module included. */ static const char *set_extended_status(cmd_parms *cmd, void *dummy, int arg) I suspect that in the modern era this is one of the less harmful ways that users can shoot themselves in the foot by changing defaults ;) Thoughts?
Re: mod_backtrace and mod_whatkilledus to trunk?
On Thu, Jan 15, 2009 at 9:31 AM, traw...@gmail.com wrote: These are in the 1.3.x branch but not trunk. From the number of hits on the web I'd guess that some folks have made tweaks to them but there's no obvious place to maintain those tweaks. (I've received a patch or two via e-mail before.) +1 -- Eric Covener cove...@gmail.com
Longevity of versions
how long will version 2.0 be available for use? Always? or until a certain date generally speaking? -- View this message in context: http://www.nabble.com/Longevity-of-versions-tp21479665p21479665.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_backtrace and mod_whatkilledus to trunk?
traw...@gmail.com wrote: Specific proposal: Take what is in 1.3 branch and port to trunk. This should be very close to http://people.apache.org/~trawick/mod_backtrace.c and http://people.apache.org/~trawick/mod_whatkilledus.c +1 in principle How do you propose to deal with configuration? Specifically, the interaction with enable-exception-hook, which means that a server built without it breaks the expectation that new modules can be added using apxs? How do they interact with compiler optimisations? Should mod_backtrace detect optimised code and warn that the backtrace printed may be affected and misleading? -- Nick Kew
Re: Apache Shutdown - Win32
Thomas Steinbach wrote:
Hello,
I have a small win32 program which starts
and stops apache (win) as a program (not service)
in a hidden console.
Well, httpd should work fine, but...
void StartApache()
{
g_sia.dwFlags = STARTF_USESHOWWINDOW;
g_sia.wShowWindow = SW_HIDE;
... does not generate a console window. You have a new process
group and no cmd.exe process leader. Try invoking with cmd.exe /c ...
and be certain you have STARTF_USESTDHANDLES as all good console
programs initially require some stdin/out/err, even if they are
pointing to an open NULL device handle.
Bill
Re: Longevity of versions
rts wrote: how long will version 2.0 be available for use? Always? or until a certain date generally speaking? Forever. It's open source, if it's broke, you get to keep both pieces (and fix them if you like). If you see http://archives.apache.org/ the foundation generally makes source code available forever. You probably wanted to ask; how long will 2.0 be maintained by the httpd project? By the time 2.4 or 3.0 httpd are final, I would expect only 2.2 and 2.4/3.0 to be maintained. That is probably another few months or a half year.
Re: Re: mod_backtrace and mod_whatkilledus to trunk?
On Jan 15, 2009 11:16am, Nick Kew n...@webthing.com wrote: How do you propose to deal with configuration? Specifically, the interaction with enable-exception-hook, which means that a server built without it breaks the expectation that new modules can be added using apxs? I may misunderstand your concern here. I think of --enable-exception-hook purely as whether the potentially-dangerous hook is available to any module. As mod_backtrace and mod_whatkilledus cannot perform a useful service without that hook, and the idea behind making the exception hook a configure option is that the user should think twice before enabling it, Apache configure should fail if backtrace or whatkilledus are enabled but the exception hook is not. How do they interact with compiler optimisations? Should mod_backtrace detect optimised code and warn that the backtrace printed may be affected and misleading? I think a warning in the documentation would be helpful to the naive. I don't think the code should be concerned with that consideration.
Re: Longevity of versions
William A. Rowe, Jr. wrote: rts wrote: how long will version 2.0 be available for use? Always? or until a certain date generally speaking? Forever. It's open source, if it's broke, you get to keep both pieces (and fix them if you like). If you see http://archives.apache.org/ the foundation generally makes source code available forever. You probably wanted to ask; how long will 2.0 be maintained by the httpd project? By the time 2.4 or 3.0 httpd are final, I would expect only 2.2 and 2.4/3.0 to be maintained. That is probably another few months or a half year. However, I expect if there was a critical security vulnerability, we would at least provide patches, and/or do a release -- lots of peoples jobs are still tied to 2.0.x :-) -Paul
Re: mod_backtrace and mod_whatkilledus to trunk?
traw...@gmail.com wrote: On Jan 15, 2009 11:16am, Nick Kew n...@webthing.com wrote: How do you propose to deal with configuration? Specifically, the interaction with enable-exception-hook, which means that a server built without it breaks the expectation that new modules can be added using apxs? I may misunderstand your concern here. There's a general expectation that you can compile modules using apxs, without having to recompile the core. So long as the fatal-exception hook is a compile-time option, your modules break that expectation. If your modules go into trunk, that puts them on track for future release versions where they'll be exposed to users who can't be expected to recompile the core. OK, come to think of it, we do have precedents, like LDAP modules requiring the optional support in APR. But at least that's moving in the right direction with APR modularisation. Ho, hum. -- Nick Kew
Re: mod_backtrace and mod_whatkilledus to trunk?
-Ursprüngliche Nachricht- Von: Nick Kew Gesendet: Donnerstag, 15. Januar 2009 18:27 An: dev@httpd.apache.org Betreff: Re: mod_backtrace and mod_whatkilledus to trunk? traw...@gmail.com wrote: On Jan 15, 2009 11:16am, Nick Kew n...@webthing.com wrote: How do you propose to deal with configuration? Specifically, the interaction with enable-exception-hook, which means that a server built without it breaks the expectation that new modules can be added using apxs? I may misunderstand your concern here. There's a general expectation that you can compile modules using apxs, without having to recompile the core. So long as the fatal-exception hook is a compile-time option, your modules break that expectation. If your modules go into trunk, that puts them on track for future release versions where they'll be exposed to users who can't be expected to recompile the core. OTOH if these modules are in trunk and you have a binary without this hook and thus without mod_backtrace and mod_whatkilledus who really tries to compile single modules from our distribution via apxs without compiling the whole thing? Another option would be to add this hook by default and prevent its execution by a directive (haven't dug into this to check if this is possible). Regards Rüdiger
Re: Longevity of versions
Thank you for answering the question that I should have asked. Paul Querna wrote: William A. Rowe, Jr. wrote: rts wrote: how long will version 2.0 be available for use? Always? or until a certain date generally speaking? Forever. It's open source, if it's broke, you get to keep both pieces (and fix them if you like). If you see http://archives.apache.org/ the foundation generally makes source code available forever. You probably wanted to ask; how long will 2.0 be maintained by the httpd project? By the time 2.4 or 3.0 httpd are final, I would expect only 2.2 and 2.4/3.0 to be maintained. That is probably another few months or a half year. However, I expect if there was a critical security vulnerability, we would at least provide patches, and/or do a release -- lots of peoples jobs are still tied to 2.0.x :-) -Paul -- View this message in context: http://www.nabble.com/Longevity-of-versions-tp21479665p21483334.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_backtrace and mod_whatkilledus to trunk?
On Thu, Jan 15, 2009 at 12:40 PM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: -Ursprüngliche Nachricht- Von: Nick Kew Gesendet: Donnerstag, 15. Januar 2009 18:27 An: dev@httpd.apache.org Betreff: Re: mod_backtrace and mod_whatkilledus to trunk? traw...@gmail.com wrote: On Jan 15, 2009 11:16am, Nick Kew n...@webthing.com wrote: How do you propose to deal with configuration? Specifically, the interaction with enable-exception-hook, which means that a server built without it breaks the expectation that new modules can be added using apxs? I may misunderstand your concern here. There's a general expectation that you can compile modules using apxs, without having to recompile the core. So long as the fatal-exception hook is a compile-time option, your modules break that expectation. If your modules go into trunk, that puts them on track for future release versions where they'll be exposed to users who can't be expected to recompile the core. OTOH if these modules are in trunk and you have a binary without this hook and thus without mod_backtrace and mod_whatkilledus who really tries to compile single modules from our distribution via apxs without compiling the whole thing? Another option would be to add this hook by default and prevent its execution by a directive (haven't dug into this to check if this is possible). which reminds me: The 2.x hook is already protected both by a configure option which defaults to no and a directive which defaults to Off ;) See http://httpd.apache.org/docs/2.2/mod/mpm_common.html#enableexceptionhook See some comments from Joe about why not to even allow the directive by default at https://bugzilla.redhat.com/show_bug.cgi?id=205627 (I've worked with customers using these modules to help diagnose problems in countless situations and don't remember where they were impediments, but I guess I wouldn't ;) That's not to say that they were always helpful, of course.)
Re: mod_backtrace and mod_whatkilledus to trunk?
On 01/15/2009 07:39 PM, Jeff Trawick wrote: On Thu, Jan 15, 2009 at 12:40 PM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: Another option would be to add this hook by default and prevent its execution by a directive (haven't dug into this to check if this is possible). which reminds me: The 2.x hook is already protected both by a configure option which defaults to no and a directive which defaults to Off ;) See http://httpd.apache.org/docs/2.2/mod/mpm_common.html#enableexceptionhook See some comments from Joe about why not to even allow the directive by default at https://bugzilla.redhat.com/show_bug.cgi?id=205627 Thanks for the pointer. I agree with Joe that it is better to analyse the core dump afterwards, but I don't see that setting AP_ENABLE_EXCEPTION_HOOK and setting EnableExceptionHook to Off really hurts us in this respect. We already catch core dump signals to change the current working dir to dump the core in the correct place. If EnableExceptionHook is set to Off we just call one additional static function (run_fatal_exception_hook) and check a static variable in an if statement. We could even integrate the code of run_fatal_exception_hook into sig_coredump without any pain. So from my current point of view I tend to say: enable enableexceptionhook by default and let EnableExceptionHook default to off (as currently). But Joe has always very good arguments, so he may make me change my mind again :-). Regards Rüdiger
Re: Longevity of versions
Paul Querna wrote: However, I expect if there was a critical security vulnerability, we would at least provide patches, and/or do a release -- lots of peoples jobs are still tied to 2.0.x :-) Right - the question is more between bug fixes (possibly disruptive to the user and certainly disruptive to the developers of 2.2 and 2.4/3.0) and security releases (quite possible for a long while to come).
[Patch] Reliable error logs for trunk
httpd has a feature called reliable piped logs. When a log process like rotatelogs dies, httpd automatically restarts it. This can be used to close open log files from outside httpd by simply killing rotatelogs. This procedure does not work for the error logs, because those are started with a different mechanism, even if they are configured with the same rotatelogs syntax. This difference goes back to pre 1.3 httpd. The patch at http://people.apache.org/~rjung/patches/reliable_error_log.patch should fix this. I tested it with access and error logs, with the main server and virtual hosts and with restarts and logger killing. The problem is the delicate handling of file descriptors in the main error log case. Should I apply this to trunk? My tests are only on Solaris. I will also test on Linux, but it would be nice if someone could test on Windows too. Some comments on the patch: 1) The piped_log_maintenance() function used as a callback when the logger dies needs one additional data, namely whether the died logger was the main error log. We could add this to the piped_log structure, but because that is public, I'm not sure whether we want to expose it like this. So I preferred to wrap piped_log into piped_log_wrapper locally. 2) I did not yet test the case where AP_HAVE_RELIABLE_PIPED_LOGS is not defined, which seems to be a very rare case. 3) To make the behaviour between CustomLog and ErrorLog more consistent I added ap_server_root_relative() for the logger path before spawning the logger. This is not necessary to achieve the reliable restarts. Regards, Rainer
