I'm still busy working on the lastest features for ModSecurity 2.6.0 so i didn't have time to try to reproduce this old bug. If you can enable a high log level and send and send me the logs will be great, i can try to see what is happening.
Christian did you reproduce this error again ?
Happened yet again.
We only had one mlogc process running at the time. No multiple
processes so I can't see resource contention being the issue.
Am I correct that this issue was supposed to be resolved in modsec 2.5.12?
Because of these repeated failures I have to stop using modsec in
production. If anyone has any other thoughts or work-arounds to this
issue I'd love to hear them.
On Wed, Mar 16, 2011 at 1:27 PM, Dan <firstname.lastname@example.org> wrote:
> This same issue just happened to us again. I was able to kill the
> pegged mlogc process and apache became responsive again. I'm confused
> by what I found after killing it though. I ran a process listing and
> not only was there a new mlogc process running, but there's another
> one with just under 14 hours of cpu time that was spawned a week ago
> that doesn't seem to have done anything since the last time I issued a
> graceful restart to apache (when this happened last time).
> Is mlogc supposed to spawn off a new process by itself when a previous
> iteration gets killed?
> How many mlogc processes am I supposed to have running at one time?
> We use logrotate to rotate our apache access and error logs.
> Post-rotation we send a "kill -HUP `pid`". I'm beginning to wonder
> that process is leaving rogue mlogc processes. Has anyone had to add
> an additional command to cleanup any leftover mlogc processes as part
> of their log rotation?
> On Wed, Mar 9, 2011 at 11:23 AM, Dan <email@example.com> wrote:
>> Hello all.
>> We have some apache installations running modsec with the following
>> versions on a RHEL5 server:
>> [root@server bin]# /usr/local/bin/mlogc -v
>> ModSecurity Log Collector (mlogc) v2.5.12
>> APR: compiled="1.2.7"; loaded="1.2.7"
>> PCRE: compiled="6.6"; loaded="6.6 06-Feb-2006"
>> cURL: compiled="7.15.5"; loaded="libcurl/7.15.5 OpenSSL/0.9.8b
>> zlib/1.2.3 libidn/0.6.5"
>> [root@server bin]# /opt/apache/bin/httpd -v
>> Server version: Apache/2.2.16 (Unix)
>> Server built: Jan 5 2011 16:38:49
>> We had been running ModSec for years now sending our logs to the
>> ModSecurity console running on a windows server, and we've had one,
>> maybe two instances on mlogc pegging a processor and apache becoming
>> unresponsive. We deployed a couple new web-servers a few months ago
>> and began using AuditConsole instead without issue, until two weeks
>> ago. Since then, we've had 4 instances where mlogc pegged and apache
>> has become unresponsive. Killing the mlogc process and restarting
>> apache seems to work in the short term.
>> I've done the requisite googling and found many postings regarding
>> this issue saying that this issue was resolved in version 2.5.9 of
>> ModSecurity, but evidently the issue still persists. I can't find any
>> more information on the status of this bug in 2.5.12.
>> Can anyone suggest a course of action on this? Is this an issue with
>> mlogc, the build, or something inherent to AuditConsole? ModSecurity's
>> been a great tool for us and I want to keep it, but the kneejerk
>> response from management is to pull the plug on it and find another
>> Many thanks,
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
mod-security-users mailing list
ModSecurity Services from Trustave's SpiderLabs: