On Wed, Oct 17, 2012 at 8:09 PM, Christopher Decker <[email protected]> wrote: > All, > > I've been running OSSEC 2.6 in my production environment for about a year > now. I recently had to re-install my OSSEC Manager (due to a recap of > hardware). Immediately after the installation I noticed that auditd was > spewing logs because the monitord process was unsuccessfully attempting to > open /logs/ossec.log. > > Eventually auditd begins consuming large amounts of CPU time, and then > monitord spins up thread after thread to try and keep up; eventually > monitord creates 1000+ threads and the server freaks out. > > Does anyone have any ideas on what the cause could be? I've never > experienced this with OSSEC and I use it heavily. At this point I'm > assuming it is something simple, as I've spent a considerable amount of time > troubleshooting :) > > Notes: > > My ossec.conf is heavily customized but obviously I do not have a > <localfile> entry for /var/ossec/logs/ossec.log. > I confirmed the permissions on /var/ossec/logs match those of an OSSEC > installation not exhibiting this behavior. The same is true for the > ossec.log file itself. > OSSEC is able to write to /var/ossec/logs/ossec.log upon start-up, though > I'm guessing the process there is not monitord > I know OSSEC is chrooted, but for the hell of it I created a symlink from > /logs/ossec.log-->/var/ossec/logs/ossec.log. This was unhelpful. > The server acting as the OSSEC Manager is beefy. > > > > > Thanks, > Chris
Is SELinux blocking it?
