On Wed, 2011-02-23 at 18:50 +0100, Valentijn Sessink wrote:
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.
It depends on what the write() syscall returns to syslog-ng. The only way to check that is to use strace on the syslog-ng process and see if writing the proc file returns failure on write or not. -- Bazsi