Trying to follow as I have the same error message from an agent that working fine for months.
Agents are running v1.4 so is server. Unfortnately I don't have a file - /var/ossec/queue/shared. Any ideas? Thanks, Eric On Sep 18, 6:34 am, "Daniel Cid" <[EMAIL PROTECTED]> wrote: > Hi Donald, > > Which version of OSSEC are you using (on the agent and server)? If > thismessageis appearing at the sever side, > can you show us the output of /var/ossec/queue/shared ? It means that > the agent is sending an improper formatedmessage(not \nterminated), which > might be caused by a truncated > output (I only saw this in the past when the > shared directory had a very large amount of files). > > *btw, how often are you seeing those? > **is your first issue resolved? > > Thanks, > > -- > Daniel B. Cid > dcid ( at ) ossec.net > > On Wed, Sep 17, 2008 at 4:13 AM, Donald Tabone <[EMAIL PROTECTED]> wrote: > > > Anyone seen this behavior before and managed to resolve it ? > > > On Sep 16, 10:54 am, "Donald Tabone" <[EMAIL PROTECTED]> wrote: > >> Whilst we have suppressed the rule <1002> from sending email alerts, we > >> also > >> noticed the following log entry is /var/log/ossec.log > > >> 2008/09/16 01:47:50ossec-remoted:Invalidmessagefrom '10.31.19.33' > >> (strchr\n) > > >> Has this got anything to do with syslog-ng/ossec generating errors. > > >> 2008/9/16 Donald Tabone <[EMAIL PROTECTED]> > > >> > Dear all, > > >> > We're experiencing this randomly generated error after we fire-up > >> > ossec. It is tending to flood our email box with alerts. > > >> > Sep 15 10:03:32 captain syslog-ng[22504]: I/O error occurred while > >> > reading; fd='69', error='Connection reset by peer (104)' > > >> > From some research we've done, using lsof the file descriptor (fd) > >> > number corresponds at any one point in time to a number of other files > >> > with different permissions. Through logical deduction we think that it > >> > is possible that when ossec tries to check a file on a particular > >> > channel, the file would have already been closed and hence the > >> > connection is reset. Are off track with this line of thinking? > > >> > We also referenced > >> >http://www.ossec.net/wiki/index.php/Know_How:Email_Alerts_below_7 > >> > and tried to tweak a rule as explained in the wiki entry - but this > >> > did not work. The result atm is that ossec service is stopped. > > >> > The questions we ask: > > >> > How can we accurately pinpoint whether ossec is the problem or not? > >> > Is this a false positive? ie. can it be ignored or is there a > >> > significant problem in the system we actually need to resolve? > > >> > We are running ossec 1.6 on a debian4 machine. (same error occured > >> > with 1.5.1) > > >> > Can someone assist in finding a solution? > >> > TY
