Balazs Scheidler schreef:
On Thu, 2011-02-17 at 16:02 +0100, Valentijn Sessink wrote:
As far as I can see, syslog-ng will not try again to deliver the same message; but is this by design? I.e. can I trust syslog-ng to not "block" because of a single malformed IP address? if a write error occurs, syslog-ng suspends the destination question for time_reopen() amount of time, then will try to write it again with the last unsuccessful write.
That is rather weird, because it's not what I'm seeing: I do see the time_reopen() messages, but after that, syslog-ng doesn't try to deliver the same message. I used the following pattern to be able to generate wrong messages: <?xml version='1.0' encoding='UTF-8'?> <patterndb version='3' pub_date='2011-02-16'> <ruleset name='valentyn' id='07d59af0-65ff-c847-9c07-ef69fa8cf50e'> <description> This ruleset covers valentyn </description> <pattern>valentyn</pattern> <rules> <rule id='foo' class="logger"> <patterns> <pattern>foo</pattern> </patterns> <values> <value name="usracct.type">login</value> <value name="usracct.sessionid">$PID</value> <value name="usracct.application">$PROGRAM</value> <value name="secevt.verdict">REJECT</value> <value name="usracct.device">KANARIE</value> </values> <tags> <tag>usracct</tag> <tag>secevt</tag> </tags> </rule> </rules> </ruleset> </patterndb> Now you can spoil your xt_recent destination with the following command: logger -t valentyn "foo bar baz" As far as I can see, syslog-ng does NOT try to re-deliver the message.
do you perhaps have a suggestion what we should do instead? bear in mind that we have to handle ENOSPC (=disk full) errors properly.
Maybe a "lost messages is not a problem" flag for certain destinations? I'm not sure. Also, whenever $usracct.device contains an IP address, there is no problem. But the larger the patterndb grows, the greater the chance that a wrong pattern slips through... Best regards, Valentijn -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sessink@openoffice.nl +31(0)20-4214059