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 > > > > >
