On Wed, Apr 25, 2012 at 8:27 AM, Valentin Avram <[email protected]> wrote:
> Which means the "initial" scan took about 29 hours (yay!), which caused > analysisd to use the CPU like nuts. At his point, the fact that OSSEC waits > for 29 hours before activating real-time monitoring is really starting to > be an issue. > > The duration syscheck takes is configured (in a way) in the /var/ossec/etc/internal_options.conf file. Change the values of the following to 0 syscheck.sleep=0 syscheck.sleep_after=0 This will speed up syscheck, but will also make syscheck consume more CPU resources. However on the server and all agents the syscheck config specifies that > /etc is to be monitored with "report_changes" set to yes. Any other > monitored folder does not have report_changes activated. > I've never used "report_changes" set to yes. But that may cause the syscheck DB to grow, if the change data is kept in the DB. > > >> >> - 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? >> > > The same file i was asking in the previous line :) aka > /var/ossec/queue/syscheck/syscheck. > > analysisd reads the whole syscheck DB when searching for the file to compare against. I didn't understand your reference to events/files/folders. Stupid question: what happens if i clear the DB (except for the file > getting way smaller)? Since I care only about changes that happen from this > moment on to a file (and i keep the logs of any other previous changes), I > don't think the file change data logged in the file would be really useful. > Did i get this right? > Clearing the DB, wipes out the previous DB. It truncates the file to 0 bytes. So the next time you run syscheck on the agent, you will not get any alerts for changed files. > > >> >> >> - 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. >> > > Oh man. > Yes I agree. :)
