[syslog-ng] Output to file in /proc

[Valentijn Sessink]

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 at openoffice.nl  +31(0)20-4214059