Bug 159639 - syslogd opens a socket on UDP port 514 even when receipt of remote log messages is disabled
syslogd opens a socket on UDP port 514 even when receipt of remote log messag...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sysklogd (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-06 09:53 EDT by Jimmy Dean
Modified: 2012-05-01 02:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-07 15:59:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 31168 None None None Never

  None (edit)
Description Jimmy Dean 2005-06-06 09:53:30 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):
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.
Comment 1 Jason Vas Dias 2005-06-06 10:09:56 EDT
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)?
 
Comment 2 Jason Vas Dias 2005-06-07 15:47:05 EDT
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.

 
Comment 3 Vlado Potisk 2005-09-15 17:58:31 EDT
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 ?
Comment 4 Harry Hoffman 2010-02-19 12:52:43 EST
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.

Note You need to log in before you can comment on or make changes to this bug.