Further update, while I haven't seen the usual "File not available error" no logs have been sent to the central server since after midnight which leads me to believe that some part of the logrotate process or this patch for alerts.log may not be quite there.
Is there any diagnostics info I can provide to help fault find this issue? Thanks, Craig On Wednesday, 18 February 2015 21:48:06 UTC, CraigL wrote: > > Applied the patch, upgraded the install on the hybrid box and it is > behaving well so far, certainly the longest it has done all day, most of > the time it would have crashed within minutes, 10 - 20 minutes maximum. > > C > > > On Wednesday, 18 February 2015 20:19:46 UTC, CraigL wrote: >> >> I have seen this issue today while testing a tiered infrastructure on >> 2.8.1, will upgrading the existing installation apply the patch or will I >> need to reinstall? >> >> Thanks, >> >> Craig >> >> >> On Thursday, 12 February 2015 12:56:01 UTC, dan (ddpbsd) wrote: >>> >>> On Thu, Feb 5, 2015 at 7:49 AM, dan (ddp) <[email protected]> wrote: >>> > On Wed, Feb 4, 2015 at 11:29 PM, John Luko <[email protected]> wrote: >>> >> Ok. I did a local setup and after sometime I was finally able to >>> recreate >>> >> the issue. Setup was as follows: >>> >> >>> >> server1 (server mode) --> server 2 (hybrid mode) ---> computer1 >>> (agent only) >>> >> >>> >> I made a series of changes to files on computer1 and it reported >>> those >>> >> changes to server 2, which were reflected on server 1 (it did not >>> show what >>> >> the hashes were). I changed the file a bunch of times for a few >>> minutes and >>> >> everything was reporting just fine. It wasn't until I performed >>> several >>> >> sudo -i commands on server2 that it reported the following: >>> >> >>> >> 2015/02/04 23:16:58 ossec-logcollector(1904): INFO: File not >>> available, >>> >> ignoring it: '/var/ossec/logs/alerts/alerts.log'. >>> >> >>> >> It stayed connected for almost 20 minutes before the above happened, >>> but in >>> >> production environments I am getting around 4 minutes before it >>> starts >>> >> ignoring that alerts.log. >>> >> >>> >> 2015/02/04 22:53:21 ossec-agentd(4102): INFO: Connected to the server >>> >> (192.168.1.2:1514) >>> >> >>> >> So, at least for now, it appears that it is related to the sudo >>> commands >>> >> being run. Anything else I can provide to help with troubleshooting? >>> Also, >>> >> is it possible for the hashes to be sent as well? >>> >> >>> > >>> > I've setup test environments, I need help tracking down the bug in the >>> code. >>> > >>> >>> I have a potential fix here: >>> https://github.com/ossec/ossec-hids/issues/442 >>> It needs some pretty heavy testing though. >>> >> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
