Red Hat Bugzilla – Bug 159639
syslogd opens a socket on UDP port 514 even when receipt of remote log messages is disabled
Last modified: 2012-05-01 02:56:39 EDT
+++ This bug was initially created as a clone of Bug #137205 +++
Description of problem:
syslogd opens a socket on UDP port 514 even when receipt of remote log messages
is disabled, as long as any forwarding entries exist in /etc/syslog.conf. If
it's not listening on port 514 why does it need to have the socket open at all.
In this case, a customer is also doing logging with syslog-ng, and whenever
syslogd is started last it blocks syslog-ng from receiving messages on the port.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add any forwarding host entry to syslog.conf
2. Restart syslogd
3. Observe open socket via 'netstat -uln | grep 514'
A UDP connection exists on port 514
No connection on port 514 since we're not accepting remote messages
Additional info:I have updated to RHEL Update 5 and am still experiencing this
sysklogd-1.4.1-26_EL3 does not have this problem.
You updated to RHEL-3-U5 with RHN ?
I've checked that sysklogd-1.4.1-26_EL3 seems to be being pushed
from our end to the RHEL-3-U5 RHN channels - which flavour / arch
of rhel-3 are you using - ie. (AS,ES,WS,Desktop)/(i386,ia64,ppc,s390)?
Sorry for the misunderstanding - I see the issue now .
Yes, when you have '* @host' forwarding statements in syslog.conf,
syslogd opens a UDP socket on port 514, in order to forward messages
to the '@host' remote logger destination. It has always used the port
514 origin from which to send log messages, so administrators can
configure firewalls accordingly.
But it NEVER does a receive on that socket unless you also have
given syslogd the '-r' command line option.
It would be unsafe and inefficient for syslogd to open and bind a
new socket for every new message sent to a remote logging host.
When syslogd enters its message processing loop, it must know that
it has acquired all the resources necessary to process any message
it might receive. Otherwise, it could transiently fail to acquire
the resources and messages might be dropped . Performance also must
be maintained, since many critical system daemons engage in
synchronous communication with syslogd, so syslogd's performance
can affect that of the whole system.
So syslogd cannot open and bind a new socket for every message sent
to a remote logging host.
The current scheme of maintaining one open socket bound to port 514
is the most efficient, cannot result in dropped messages, and
presents no security vulnerabilites or any known problems whatsoever.
What problems does this open socket cause ? I can think of none.
Hence, this bug is being closed as "NOTABUG" . If you disagree,
please provide specific details of problems caused by this open
socket and re-open this bug - thank you.
Syslogd opens the UDP port 514 for sending as described above, but it does not
receive on it (unless the -r option is specified, of course).
Under these circumstances it's possible to send data to this port until the
receive queue gets full and thus waste some amount of memory. Wouldn't it be
better to read and discard incoming datagrams in this situation ?
I'd like to re-open this bug. Syslog when forwarding messages binds to udp *:514 which prevents other applications from being able to bind to udp <public_ip>:514.
In my instance I have a application that needs to listen on public_ip:514 but I also need to forward local logs to the main syslog server for our institution.