Rsyslog Listening On High Port

Home » CentOS » Rsyslog Listening On High Port
CentOS 7 Comments

Attempting to lookup why rsyslogd is listening on the high port UDP/51427. Have not succeeded in what this port is used for and what directive controls what interface it binds to.

[root@bedrock ~]# netstat –listen –inet –program –numeric | grep syslog udp

7 thoughts on - Rsyslog Listening On High Port

  • I don’t think that is really rsyslogd running.. first rsyslogd usually is running with a much lower pid as it starts early on. All the boxes I saw had it running under 1000. If the system is set up to actually listen to the internet it will look like

    [root@log01 ~][PROD]# netstat –list –inet –program –numeric | grep rsys tcp 0 0 0.0.0.0:514 0.0.0.0:*
    LISTEN 1078/rsyslogd tcp 0 0 0.0.0.0:5000 0.0.0.0:*
    LISTEN 1078/rsyslogd udp 0 0 0.0.0.0:514 0.0.0.0:*
    1078/rsyslogd

    and those are set in /etc/rsyslogd.conf

    [root@log01 ~][PROD]# egrep ‘514|5000’ /etc/rsyslog.conf
    $UDPServerRun 514
    $InputTCPServerRun 514
    $InputTCPServerRun 5000

    I would do a ps auxww | grep 66655 and see what is running and then check to see if that binary is what it is supposed to be.

  • Adam,

    You might want to try running:

    lsof -i -P | grep LISTEN | grep :51427

    to determine what process is actually listening to that port.
    —
    Mike Burger http://www.bubbanfriends.org

    “It’s always suicide-mission this, save-the-planet that. No one ever just stops by to say ‘hi’ anymore.” –Colonel Jack O’Neill, SG1

  • That is what is strange; lsof does *not* see the port as listening, but it is visible if I search by inode [and it is clearly rsyslogd –
    but I cannot find any documentation indicating what this is].

    [root@bedrock ~]# netstat –inet –program –numeric –listen | grep syslog udp

  • because there is no LISTEN in the lsof output for UDP ports.

    just execute

    lsof -i :51427 -P

    should show you the process.

    best regards Ulf

  • The 51427 is the ephemeral port on the client side of the UDP
    session. You can verify this by running tcpdump to capture traffic when a syslog message is passed.

    I can report that I also see this netstat (and similar with ss) state for systems with rsyslog set up to send to a remote log server, where ss reports that the process has UNCONN state on high UDP ports.

    I suspect it’s part of the UDP handshake that rsyslog uses for sending syslogs, but I’m not familiar enough with how it works to say definitively. Since it’s UDP, it’s a sessionless protocol, so it’s not strictly LISTENing, but with ss you can see it’s UNCONN, which other daemons that *are* listening for UDP traffic also report.

    It is quite interesting to me, and if anyone knows why this works this way, I’d be happy to hear. I did some tests with ‘nc -u’ and I
    couldn’t get similar results.

  • Thanks, I was suspecting something like this as the only way to make that port disappear was to disable remote logging.

    It was puzzling because I can’t find any reference to this behavior in any documentation.

    Right, distinguishing between the listening and open in UDP is always somewhere between tedious and impossible. Perhaps I should investigate logging over TCP! :)

    Anyway, I have something to write in the report now.

  • That makes perfect sense. I had checked several boxes on our side and had not found any with that port being shown but we use TCP for logging so I expect that is why. My apologies to Mr Billings for going for the worst possible scenario.