+++ 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): sysklogd-1.4.1-12.3 How reproducible: Always Steps to Reproduce: 1. Add any forwarding host entry to syslog.conf 2. Restart syslogd 3. Observe open socket via 'netstat -uln | grep 514' Actual results: A UDP connection exists on port 514 Expected results: 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 problem.
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 ?
Hi, 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.