Hi Dan,

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 ?

Thanks Srs

Breno

On Fri, Mar 18, 2011 at 4:17 PM, Dan <random.danno@gmail.com> wrote:
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.

Thanks,

Dan

On Wed, Mar 16, 2011 at 1:27 PM, Dan <random.danno@gmail.com> 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?
>
> TIA
>
> Dan
>
> On Wed, Mar 9, 2011 at 11:23 AM, Dan <random.danno@gmail.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
>> solution.
>>
>> Many thanks,
>>
>> Dan
>>
>

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
ModSecurity Services from Trustave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php