On Fri, Apr 20, 2012 at 11:36 AM, Valentin Avram <[email protected]> wrote:
> The problem is not the syscheck process ... > The problem is the analysisd process and ONLY on ossec services restart (i > did not try to restart only the analysisd process and see if it does the > same - probably it does). > > On restart, syscheck starts running a scan and analysisd will be receiving the information right away and comparing it with the data in the syscheck DB. (syscheck only reads the file info and analysisd compares the present state with the information in the DB) Since your trace revealed a lot of reads on the queue/syscheck/syscheck file, I'm still guessing that it is the size of this file which is causing analysisd to use a lot of CPU. Is it possible for you to test this by clearing up the syscheck DB and restarting ossec. If analysisd does not hog the CPU then you know that the size of the syscheck file is the issue. > About analysisd, from what i understand: > - why the /var/ossec/queue/syscheck/syscheck file never gets smaller - > about 2 weeks ago on a ossec services restart i noticed it had the same > size (230-240 MB); since it's in a folder called "queue" i would expect > events to be removed from a file once they are processed. > Short answer - to keep history about the file changes. Once ossec detects a file change, it comments out the existing entry in the syscheck DB and adds a new entry at the end of the file. If you have auto_ignore set to "no", this will cause the DB to keep growing over time. - why does the analysisd re-read the whole file - including > events/files/folders from months ago or even one year ago - i noticed that > on the strace. Which file are you referring to? > - why is it random-seeking and reading only in 4K blocks (can the read > buffer be tuned?) > > > Analysisd gets a filename and its sum data and then does a full scan of the syscheck DB file to find that filename. After every file is goes back to the beginning of the file and does a full scan again.
