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