oops, one thing that occured to me just now.
RS_RET_DISCARDMSG
is probably not what you want. This totally *discards* the message from
the queue. This state was introduced for the discard action. For
example, if your config ist
*.* ?dynafile
*.* file1
*.* file2
and you get in issue during ?dynafile processing, the message will
never be written to file1 and file2. So it is better to leave it at
RS_RET_ERR. This, however, brings us close to the code as it currently
is (except for the additional flag, which I am trying to understand ;))
Rainer
On Thu, 2008-12-18 at 15:58 +0100, Rainer Gerhards wrote:
> Hi William,
>
> I had another look at the code. I am not picky, I just want to make
> sure
> I understand the failure scenario. The v3 versions have a different
> approach at this, and I need to be sure I understand the issue so that
> I
> can check the newer releases for it.
>
> more inline below...
>
> On Thu, 2008-12-18 at 14:35 +0100, William Tisäter wrote:
> > Hi,
> >
> > Lets see if I can get this right:
> >
> > My modification in prepareFile() will return with (pData->fd = -1)
> if
> > the log file can't be created.
> > In prepareDynFile() we run prepareFile() and return with -1 if
> pData-
> > >fd is set to -1.
> > In writeFile() we run prepareDynFile() and return RS_RET_ERR if
> > prepareDynFile() is not returned with 0.
> >
> > writeFile() is wrapped in doAction().
> >
> > doAction() is exectued in fprintlog() where RS_RET_ERR never will be
> > catched.
>
> Well.. kind of. I do not check for a specific error state, but I check
> if all went well (if iRet == RS_RE_OK). Only then the previous count
> is
> reset, otherwise it is left as is. An output module may return a large
> number of errors, so it is not sufficient to check for a specific
> error
> case. That's also why I am trying to understand the issue you still
> see.
> I am sure it can occur under other circumstances, too (as I said,
> there
> are various error codes).
>
> > I discard the log message and sets the error flag to tell the
> > "msg repeated"-check to not log this message ("msg repeated" is
> > executed before we try to open the file if the message content match
> > the previous message).
>
> ... but this is done via fprintlog(), so the logic to try open the
> file
> is still included.
> >
> > I tried without this catch in the first attempt, but I could see the
> > message stuck in the loop,
>
> As of my understanding, it should not be the very same message,
> because
> that is discarded. It can be the next message, which of course will
> trigger the "last message repeated n times" text.
>
> > every action to rsyslog tried to open the
> > file. This and some traffic volume caused rsyslog to hang (and use a
> > lot of i/o).
>
> Do you have a procedure to reproduce that? Would be most interesting.
>
> As a side-Note, I think there is a memory leak in the patch, you will
> probably want to correct it. The return in line 3392 does not do the
> necessary cleanup (the return further UP is a different case, see its
> comments). Use "ABORT_FINALIZE(RS_RET_DISCARDMSG);" instead, it will
> invoke the finalizer, which will free some string space.
> >
>
> Rainer
> >
> > William Tisäter
> >
> > Blocket.se - Sveriges största Köp & Sälj marknad
> > http://www.blocket.se/
> >
> > On Dec 18, 2008, at 12:01 PM, Rainer Gerhards wrote:
> >
> > > Hi William,
> > >
> > > thanks for the bug report and the patch. I have now looked into
> the
> > > issue and could reproduce the situation. The patch obviously
> > resolves
> > > it.
> > >
> > > There is one thing, though: I do not fully understand why you have
> > > patched syslogd.c (RS_RET_ERR). I would appreciate if you could
> > > provide
> > > a bit more insight into the problem you intend to solve. So far, I
> > can
> > > not see why this part of the patch is actually needed.
> > >
> > > I'll integrate the omfile part now. I will also see that I apply
> > > this to
> > > the other official branches.
> > >
> > > Thanks,
> > > Rainer
> > >
> > > On Tue, 2008-12-16 at 17:39 +0100, William Tisäter wrote:
> > >> Hi,
> > >>
> > >> I don't know if this is an intended feature or not, but when
> > >> CreateDirs is set to off, rsyslog can no longer create files
> (time
> > >> stamp file names). Lets say you have a template for writing
> > files: /
> > >> log/<tag>/<date>.log, this will let anybody to create directories
> > >> in /
> > >> log when CreateDirs is on. This may cause a lot of directories
> and
> > >> can
> > >> be abused by regular users.
> > >>
> > >> I've patched 2.0.2 to separate file and directory creation here:
> > >> https://bugzilla.redhat.com/attachment.cgi?id=327100
> > >>
> > >> And steps to reproduce this can be found here:
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=473419
> > >>
> > >> Comments anyone?
> > >>
> > >>
> > >> William Tisäter
> > >>
> > >> Blocket.se - Sveriges största Köp & Sälj marknad
> > >> http://www.blocket.se/
> > >> _______________________________________________
> > >> rsyslog mailing list
> > >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> > >> http://www.rsyslog.com
> > >
> > > _______________________________________________
> > > rsyslog mailing list
> > > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > > http://www.rsyslog.com
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com
> >
> >
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
