The agent hosts that show this problem are Linux 2.6 hosts running either Fedora Core 5 or Centos 5. Beyond that, I cannot tell you much more (because there is not much more to tell :)) The problem occurs intermittently (as in not very often) and is immediately corrected whenever the rids queues are taken care of as described above. While the specified active response is not triggered when the problem occurs, the agent involved is nevertheless recognized by agent_control as active. I hope the description helps.
On Oct 29, 10:47 am, "dan (ddp)" <[email protected]> wrote: > I've never seen this problem. In fact I've never had to clear out the > rids files. > Can you provide a bit more information about the hosts showing this problem? > > > > > > > > On Thu, Oct 28, 2010 at 1:31 PM, blacklight <[email protected]> wrote: > > Hello Folks, > > > Once in a while, the active response does not kick in. Then I have to > > go into /var/ossec/queue/rids of the OSSEC agent host and to delete > > the agent ID file, say "011", and restart OSSEC at the agent. And I > > have to go into/var/ossec/queue/rids of the OSSEC server host, delete > > the agent ID file there - in this case, "011", and restart OSSEC at > > the server. At which point, active response will kick in if the > > appropriate rule is triggered through the agent's syslog. > > > My question is "why do I have to this house cleaning"? It is as if the > > lines of communication between OSSEC server and OSSEC agent that > > pertain to active response just went dead, and I have to compel the > > OSSEC agent and OSSEC server to shake hands again.
