Eric - we also noticed that with OSSEC off we are still getting IO errors reported from Syslog-ng.
Still investigating.. D. -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 4:31 PM To: ossec-list Subject: [ossec-list] Re: "connection reset by peer(104)" condition 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
