Thanks! Yes, that was very useful. Can you try the following snapshot:
http://sucuri.net/files/snapshot/ossec-hids-101007.tar.gz Should have fixed it. thanks, On Wed, Oct 6, 2010 at 10:24 PM, Chris Decker <[email protected]> wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 644] > 0x00000039e8a7275e in free () from /lib64/libc.so.6 > (gdb) > (gdb) > (gdb) > (gdb) bt > #0 0x00000039e8a7275e in free () from /lib64/libc.so.6 > #1 0x000000000040eeaa in Free_Eventinfo (lf=0x79cd40) at eventinfo.c:580 > #2 0x0000000000403a94 in OS_ReadMSG (m_queue=6) at analysisd.c:1122 > #3 0x0000000000402f2c in main (argc=1, argv=0x7fffffffe7b8) at > analysisd.c:527 > > Does that tell you anything useful? > > > > > On Wed, Oct 6, 2010 at 1:11 PM, Daniel Cid <[email protected]> wrote: >> >> Hi Chris, >> >> Can you run analysisd under gdb? I am using this option on many installs >> without any issues. >> >> Just stop OSSEC and run: >> >> # gdb /var/ossec/bin/ossec-analysisd >> >> inside GDB's shell: >> >> (gdb) set follow-fork-mode child >> (gdb) run >> >> After that, on another terminal start the other processes: >> >> # /var/ossec/bin/ossec-remoted >> # /var/ossec/bin/ossec-syscheckd >> # /var/ossec/bin/ossec-logcollecotr >> >> When analysisd crashes, run "bt" and send us the output. >> >> Thanks! >> >> >> >> On Wed, Oct 6, 2010 at 11:24 AM, Chris Decker <[email protected]> wrote: >> > Michael, >> > >> > Thank you for replying... >> > >> > I used a fresh install of 2.5 for the manager and agent. When I began >> > experiencing these issues, I started upgrading with snapshots to see if >> > the >> > issue had been fixed. >> > >> > I agree it is strange that I'm the only one having the issue--perhaps >> > the >> > report_changes option isn't used much yet? Even stranger is that I've >> > experienced it on my VMs at home AND in my lab environment at work, >> > making >> > me think it was a misconfiguration. However, my test configuration is >> > nothing fancy and is very barebones, so I highly doubt it is a >> > misconfiguration. >> > >> > Yes, I experience crashing when using syscheck with realtime >> > disabled and >> > report_changes=on. >> > >> > I'm willing to do whatever it takes to get this resolved. I've been >> > posting >> > to the IRC channel at night, but it seems most people are out living >> > there >> > lives when I get on after work. If someone could walk me through using >> > the >> > debugger at night perhaps we could get some clues on the issue. >> > >> > If you have any suggestions I'll give them a shot..I'm out of ideas! >> > >> > >> > >> > >> > Thanks, >> > Chris >> > >> > >> > >> > On Wed, Oct 6, 2010 at 10:10 AM, Michael Starks >> > <[email protected]> wrote: >> >> >> >> On Tue, 5 Oct 2010 21:23:03 -0400, Chris Decker <[email protected]> >> >> wrote: >> >> > A quick update: >> >> > - The new Snapshot released today (which appears to be destined to be >> >> the >> >> > 2.5.1 release) does not fix my problem as noted below. >> >> > - I was re-reading the documentation and noticed this statement: >> >> > "Real >> >> time >> >> > only works with directories, not individual files. So you can monitor >> >> the >> >> > /etc or C:program files directory, but not an individual file like >> >> > /etc/file.txt.". I knew this already, but tried my configuration >> >> > with >> >> > realtime disabled and still experience this issue. >> >> >> >> Are these new installs or upgrades? Strange that you seem to be the >> >> only >> >> one reporting this so far. I am running it on CentOS 5.5 and am not >> >> having >> >> any issues. And you also experience OSSEC crashing with just regular >> >> syscheck and not realtime enabled, but with report_changes enabled? >> >> >> >> -- >> >> [I] Immutable Security >> >> Information Security, Privacy and Personal Liberty >> >> http://www.immutablesecurity.com >> > >> > > >
