It sounds like the process ossec-syscheckd handles all three events I was seeing: the scan_on_start/database building for both syscheck and rootcheck (where ossec-syscheckd jumped up to 40%), then the actual syscheck (which didn't show up as using CPU because it's limiting itself), and finally rootcheck (which also jumped to 40%). And ossec- agentd only showed up because it needed to talk to the manager during syscheck.
We've been trying for a while to figure out where rootcheck lives, since in the logs it's listed as "rootcheckd" but there is no ossec- rootcheckd process. It sounds like what you're both saying is that ossec-syscheckd is also ossec-rootcheckd. Is that correct? And does this mean that if our machines are hypersensitive to rootcheck grabbing 40% CPU, we can re-nice/re-prioritize ossec- syscheckd so that rootcheck will behave a little better? Thanks! -Alisha
