On Mon, 15 Dec 2008, Rainer Gerhards wrote: > On Sun, 2008-12-14 at 04:56 +0100, Patrick Shen wrote: >> Hi Rainer, >> >> Rainer Gerhards wrote: >>> I seem to have overlooked the initial message (spam filter maybe...). >> >> Bad luck for my mail account :-( >> >>> HKS is right (thx), but I think this looks like a bug in that the output >>> write does not care about the write failure (what it should). The output >>> writer is pretty old legacy code, so that's quite possible. I'll look >>> into it ASAP, but I got a new machine (hopefully fast enough to disply >>> some troubles) today and currently I am happy that at least mail does >>> work again (so far it's a mess). So... some time next week ;) >> >> Quite appreciate if you have a look at write failure. I think it's quite >> Enterprise demand feature :-) > > I have now verified that the code (by intension) ignores write errors. > That, of course, is legacy from a long gone era. However, I need to > think a bit about how to handle this most intelligently. The problem is > partial writes. Maybe I just try to write a LF after a failure and, if > that succeeds, simply continue. This results in a partial record begin > written and then the same record being "duplicated" (actually, the > partial part being duplicated). > > Does anyone have a suggestion on how to best handle such a case? Or I > could try to write what could not yet be written. Maybe this is better, > but it wont' be able to survive a daemon restart... > > Feedback appreciated.
this sounds like a smaller portion of the problem we were discussing when we were talking about de-queuing multiple messages. this approach would work, but if you know you have a file you could also truncate the file to the end of the previous record (the beginning of the record you are trying to write). David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
