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
