When replacing (overwriting) an so module, Apache needs to be down (probably platform dependent, but definitely on Linux and Windows). I believe you can get by by doing something like, move (rename) existing so, move in new one, graceful restart (not a "graceful" ie reload, but "graceful-stop" followed by "start"), then remove renamed so, but this seems overkill and you should just take a maint window.
Thanks for the feedback. -B On Fri, Apr 15, 2011 at 12:57 PM, Andrew Pimlott <[email protected]> wrote: > Following up on a very old thread (below). Brian, thanks for your very > useful instructions, and sorry for not following them sooner. > > Excerpts from Brian Rectanus's message of Sat Mar 20 14:51:16 -0700 2010: >> Often if you upgrade/replace mod_security2.so on a running httpd you >> will see this (repeating segfaults) until you RESTART httpd. This is my > > In short, I did not (the Debian package did not) restart apache after > installing mod_security, only graceful restarted, which you indicate is > not a supported way to install or upgrade. That's all anyone needs to > read, but just for completeness: > > I got the core dump using your instructions, but running gdb on it > produced the same stack trace that I originally posted in the Debian > bug: > > ... > ap_process_request > ap_run_log_transaction > (mod_security) > apr_global_mutex_lock > segfault > > Not sure why the trace up to ap_run_error_log didn't look as expected. > I am using the prefork MPM, apache 2.2.9 from Debian lenny > (2.2.9-10+lenny9), and mod_security 2.5.11 from Debian lenny-backports > (2.5.11-1~bpo50+1). > > The steps to reproduce: > > 1. Start apache without mod_security installed (or configured obviously). > > 2. Configure mod_security. My config is very simple: > > SecRuleEngine On > SecAuditEngine RelevantOnly > SecRequestBodyAccess On > SecRequestBodyLimit 1073741824 > SecRequestBodyNoFilesLimit 65536 > SecAuditLog /var/log/apache2/post.log > SecAuditLogParts AIZ > SecRule REQUEST_METHOD POST nolog,auditlog > > No core rules or anything. > > 3. Install mod_security via the Debian package. This reloads (graceful > restarts) apache. > > 4. Make a request that would trigger audit logging (POST request). > Segfault. > > 5. Reload apache again--no more segfaults! Probably a fluke. > > I think the resolution, for the Debian bug, is that apache must be > restarted, not just reloaded after libapache-mod-security is installed. > Or, based on my experiments, you could reload it twice. :-) > > Andrew > > Excerpts from Brian Rectanus's message of Sat Mar 20 14:51:16 -0700 2010: >> Alberto Gonzalez Iniesta wrote: >> > Hi, >> > >> > I got this [1] bug report about ModSecurity segfaulting. I couldn't >> > reproduce it, it may be related to the arch of the reporter (x86_64). >> > Please, feel free to write to the bug report ([email protected]) if >> > you need further information. >> > >> > Thanks, >> > >> > Alberto >> > >> > >> > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574376 >> >> Normally a backtrace of the thread/process causing the core will show >> something like this: >> >> #0 0x00007f05edc257d0 in ?? () >> No symbol table info available. >> #1 0x000000000044990d in ap_run_error_log () >> No symbol table info available. >> #2 0x0000000000448678 in log_error_core () >> No symbol table info available. >> #3 0x00000000004487a3 in ap_log_error () >> No symbol table info available. >> #4 0x000000000044f12a in sig_coredump () >> No symbol table info available. >> #5 <signal handler called> >> No symbol table info available. >> #6 0x00007f05edc257d0 in ?? () >> No symbol table info available. >> #7 0x000000000044990d in ap_run_error_log () >> No symbol table info available. >> >> So I am thinking that this backtrace is not of the thread/process that >> caused the segfault. >> >> Often if you upgrade/replace mod_security2.so on a running httpd you >> will see this (repeating segfaults) until you RESTART httpd. This is my >> best guess given the info here. In order to do more I need a backtrace >> generated from a core. Can you configure Apache to dump core and >> reproduce it? >> >> Make sure there is a core dump area with something like: >> >> CoreDumpDirectory /tmp >> >> Make sure limits are set to dump core: >> >> ulimit -c unlimited >> >> Restart and trigger the error. A core file should be in the directory >> you specified. >> >> Then use gdb to get a backtrace: >> >> 1) gdb /path/to/httpd /path/to/core >> 2) within gdb enter: >> >> thread apply all bt full >> >> You can get it into a file with something like: >> >> gdb /path/to/httpd /path/to/core --batch --quiet \ >> -ex "thread apply all bt full" > backtrace.log >> >> See also: http://httpd.apache.org/dev/debugging.html >> >> Other issues may be what MPM use used. There may be some issues with >> mod_security that was compiled with prefork Apache without threads in >> APR and then installed in an httpd with worker MPM (or vice versa). >> Alberto, can you shed some light here? >> >> Also, if it truly is failing around the global mutex lock, then you can >> avoid this by changing from the default Serial logging (which locks) to >> the non-locking Concurrent type: >> >> SecAuditLogType Concurrent >> >> If this fixes the issue, then I'd really want a proper backtrace so I >> can look into that further. ;) >> >> thanks, >> -B >> >> -- >> Brian Rectanus >> Breach Security >> > > > > -- > To unsubscribe, send mail to [email protected]. > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
