Re: Best practice for handling synchronous signals SIGFPE etc
On 04/20/2015 03:50 PM, Mark Taylor wrote: I found that ./server/mpm_unix.c is registering a handler (sig_coredump) for SIGFPE, SIGSEGV, and other synchronous signals. I'd like to handle at least these two in my module, using my own handler. But then how do I determine if the the handler is called on a request thread or a server thread? And I'd like to default to still run the sig_coredump() function if it's signal is not in my module. Does anyone have experience with this? Regards, Mark A hook is provided for a module to perform some processing for coredump-ing signals, but the hook can't be used to prevent httpd from performing the usual sig_coredump work. mod_whatkilledus is a module that uses that particular hook and understands when a request or connection is active. There's info and a download link at http://emptyhammock.com/projects/httpd/diag/index.html
Re: Best practice for handling synchronous signals SIGFPE etc
On 2015-04-20 21:50, Mark Taylor wrote: I found that ./server/mpm_unix.c is registering a handler (sig_coredump) for SIGFPE, SIGSEGV, and other synchronous signals. I'd like to handle at least these two in my module, using my own handler. But then how do I determine if the the handler is called on a request thread or a server thread? And I'd like to default to still run the sig_coredump() function if it's signal is not in my module. Have a look at the man-page of sigaction and getcontext. When you set a signal handler you get the old signal handler (3rd argument of sigaction). So you can store it in a variable. In your own signal handler you do want you intend to do and at the end you call the old signal handler. In this way you can call sig_coredump. However you have to make sure that you set your signal handler _after_ apache has set his. Otherwise apache will replace yours. Have a look at the siginfo_t structure that is passed by the OS to your handler. You can get the program ID and the user ID from that structure. But not the thread apparently. Anyway, at least you can determine if the signal was raised in the parent or one of the worker children. Look also at the ucontext structure (man getcontext) that is passed to your signal handler. Maybe you can determine the source of the signal from that structure, though I think it's too close to machine code and registers to be useful. Alternately, you could use a thread-local variable (https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html). The first thing you do when you enter each function of your module is to set the variable. Whenever you exit a function you reset it. Thus, you may determine in your signal handler by inspection of the variable if the signal was raised by your module. (This works only if the signal handler is executed in the thread where the signal was raised which is not always the case. Otherwise you'll set some variable in your thread and read another one in the handler. Here's some information: http://stackoverflow.com/questions/11679568/signal-handling-with-multiple-threads-in-linux. Apparently the handlers for SIGSEGV and SIGFPE are called in the thread that raised them but it's not clear.) Sorin
Re: namespacing in mod_ssl
On Apr 20, 2015 2:32 AM, Joe Orton jor...@redhat.com wrote: On Thu, Apr 16, 2015 at 06:42:04AM +0200, Kaspar Brand wrote: On 15.04.2015 18:36, Stefan Sperling wrote: However, the actual issue here is that mod_ssl is squatting the SSL_ namespace. Historically this may have made sense (it seems mod_ssl and OpenSSL have shared history/authors). Bill Rowe suggested to try moving mod_ssl's functions into the ap_ namespace to avoid such clashes in the future. Agreed that mod_ssl should avoid stepping into the SSL_* yard. As pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, and my preference is for s/SSL_/ssl_/ for functions and s/SSL_/MODSSL_/ for constants (in the latter case, there's actually quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). It would be safer to go with a modssl_ prefix for functions too, I've sometimes tried to use that for new things though probably not consistently. OpenSSL's libssl.so does export symbols using the ssl_ prefix, though they are probably all internal things which shouldn't be global. I concur, but can we quit playing fetch me a rock? modssl_*() namespace? Final answer? +1 here to either ssl_ or modssl_
Re: Happy 20th Birthday, httpd
On Mon, 20 Apr 2015 08:40:50 -0400 Rich Bowen rbo...@rcbowen.com wrote: For those that missed ApacheCon last week in Austin, I wanted to share a few things. This year marks the 20th birthday of the Apache httpd project Pedantic point. Not exactly. The Apache HTTPD project came into being with the ASF. The project born in 1995 was a web server just called Apache. OK, I guess you're right. It's just the difference between a maiden name and taking on your master's name ;) -- Nick Kew
Happy 20th Birthday, httpd
For those that missed ApacheCon last week in Austin, I wanted to share a few things. This year marks the 20th birthday of the Apache httpd project (or late last year, depending on how you count) and so we had a little celebration. The feather that was made for the Apache conference in 1998 - https://www.flickr.com/photos/iamamoose/63963722/ - was at ApacheCon, and we tried to stage the same photo again, as much as was possible: https://plus.google.com/u/0/+RichBowen/posts/Gfs1Ek6MWqu We also took pictures with all of the httpd committers who were present (although I expect we missed a few people.) : https://www.flickr.com/photos/rbowen/sets/72157651553317030/ And, we had a birthday cake https://www.flickr.com/photos/linuxfoundation/17157208981/ https://www.flickr.com/photos/linuxfoundation/16537678153/ There's lots more ApacheCon photos here: https://www.flickr.com/photos/linuxfoundation/sets/72157651931911042 We're very proud of what we've accomplished over the last 20 years, and I'm pretty excited about the next 20. Thank you, every one of you, for being part of this journey, whether you've been here one day or the whole 20 years. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: namespacing in mod_ssl
On Thu, Apr 16, 2015 at 06:42:04AM +0200, Kaspar Brand wrote: On 15.04.2015 18:36, Stefan Sperling wrote: However, the actual issue here is that mod_ssl is squatting the SSL_ namespace. Historically this may have made sense (it seems mod_ssl and OpenSSL have shared history/authors). Bill Rowe suggested to try moving mod_ssl's functions into the ap_ namespace to avoid such clashes in the future. Agreed that mod_ssl should avoid stepping into the SSL_* yard. As pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though, and my preference is for s/SSL_/ssl_/ for functions and s/SSL_/MODSSL_/ for constants (in the latter case, there's actually quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.). It would be safer to go with a modssl_ prefix for functions too, I've sometimes tried to use that for new things though probably not consistently. OpenSSL's libssl.so does export symbols using the ssl_ prefix, though they are probably all internal things which shouldn't be global. Regards, Joe
Disabling SSLv3 by default (Bug 57120)
Hi guys, can we have some discussion on what is plan for this bug? https://bz.apache.org/bugzilla/show_bug.cgi?id=57120 Thanks, Petr
Best practice for handling synchronous signals SIGFPE etc
I found that ./server/mpm_unix.c is registering a handler (sig_coredump) for SIGFPE, SIGSEGV, and other synchronous signals. I'd like to handle at least these two in my module, using my own handler. But then how do I determine if the the handler is called on a request thread or a server thread? And I'd like to default to still run the sig_coredump() function if it's signal is not in my module. Does anyone have experience with this? Regards, Mark
