[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] syslogd uses inet socket excessively

From: Mats Erik Andersson
Subject: Re: [bug-inetutils] syslogd uses inet socket excessively
Date: Fri, 11 Feb 2011 11:11:42 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

tisdag den  8 februari 2011 klockan 14:19 skrev Alfred M. Szmidt detta:
>    Concerning the second action I would like to hear oppinions as to
>    performance losses caused by repeated creation of the UDP socket.
> Only way to know that is to do a benchmark, though I think we need not
> to worry.
>    Are there other syslog servers that depend on incoming messages
>    having their origin at port 514/syslog? This is the present
>    behaviour of IU-syslogd when forwarding messages.
> I don't think so; but I am not sure.  What does BSD's syslogd do?

As it turns out, OpenBSD as well as FreeBSD use a "shutdown(fd, SHUT_RD)"
like I myself do for solution 1., in order that the socket not be receiving.

Therfore the non-receiving socket "udp/514" is alive in OpenBSD and FreeBSD,
with the additional setting that FreeBSD implements (duplicate "-s") with

   syslogd -s -s

which corresponds in effect to our "--no-forward".

OpenBSD undertakes no further measurements regarding socket numbers.

On the other hand, FreeBSD has implemented a kind of ACL for admission
of foreign messages from remote hosts. The command line argument is

    syslogd -a host[:service]

When the service is not mentioned, the parser inserts "syslog/514"
as only allowed remote port. The specification

    syslogd -a myhost.ex:*

parses as allowing arbitrary remote ports. In summary, there is now
one known situation in which an originating port is tested to be "udp/514".

Reading through the manual pages that go with Rsyslogd, present on
Debian GNU/Linux (since GNU/kFreeBSD uses IU-syslogd), there is nothing
to suggest that messages are or could be filtered for port "514/udp".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]