On Fri, Oct 19, 2012 at 8:59 AM, Christopher Decker <[email protected]> wrote: > Dan, > > I'm off today, so I won't be able to provide the logs until tomorrow. They > simply say that an opened (syscall=2) failed on /logs/ossec.log. >
I still want to see them. It'll help me troubleshoot your problem. > Originally I was NFS (v4) sharing that partition to another box that ran log > stash. I have since removed that share but continue to see the same > issues--I suspected that to be the root of the issue, but I have since > reverted all of those changes and the problem persists. > Did the problem exist before this? > I performed my OSSEC install by running the install.sh script (and had > pre-compiled OSSEC). > Maybe try a full installation. Does ossec-monitord continue to run? Have you tried running it in debug/foreground mode to see what happens? > > > > On Oct 19, 2012, at 8:39 AM, "dan (ddp)" <[email protected]> wrote: > >> On Thu, Oct 18, 2012 at 5:07 PM, Christopher Decker >> <[email protected]> wrote: >>> No. SELinux is turned off. >>> >>> Sent from my iPhone >>> >> >> Please provide the auditd logs (I should have asked for that in the >> first email). Are there any special mount options on the partition >> your OSSEC installation exists on? What kind of install did you do? >> Did you just use the install.sh script? >> >>> On Oct 18, 2012, at 8:50 AM, "dan (ddp)" <[email protected]> wrote: >>> >>>> 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? >
