3

I have a CentOS 5.8 machine (with regular syslog) that for some reason is listening to port 514, even though it is not started with "-r" (to receive remote syslog messages).

# netstat -tulpn | grep 514
udp        0      0 0.0.0.0:514       0.0.0.0:*  2698/syslogd

Syslog is started with only "-m 0":

ps -ef | grep syslogd
root      2698     1  0 15:55 ?        00:00:00 syslogd -m 0

I have tried starting it with "-m 0 -r", just to check if there was any difference, but there is not.

This machine is a client and should only log to a central log server - it should not be listening itself.

What am I missing?

I just found this: https://bugzilla.redhat.com/show_bug.cgi?id=137205. From the last comment made in 2010, it appears this is a bug from 2004 that has still not been resolved (it has only been 8 years...)

Improve this question

3 Answers 3

Reset to default
3

I just did some testing, and while the port is definitely opened by syslogd, it doesn't look like it's actually handling or logging any activity directed to it on UDP 514. You can verify this by sending data with netcat:

topher@nexus:~$ nc -u localhost 514
This is a test.
This is another test.
^C

And then checking the logfile. I tested it on two RHEL5 boxes, and if -r isn't used, it won't actually process the logs.

Update: Another solution (or, really, work-around) that I just thought of would be to install rsyslog (or syslog-ng) as a replacement syslog daemon for the default sysklogd. Neither of these alternate syslog daemons suffer from the bug described above.

rsyslog is the default syslog daemon with RHEL 6.x, and is available as a supported package for RHEL/CentOS 5.2+. rsyslog is under active development (sysklogd is not, and hasn't been for years). rsyslog also supports many advanced features and functionality. As mentioned, with RHEL/CentOS 5.2+, switching from the stock syslogd to rsyslog is as easy as yum install rsyslog.

If you do decide on replacing your syslog daemon, and you want something cleaner and more flexible (in my opinion), Syslog-NG is worth taking a look at. The config file doesn't maintain backwards compatibility with the old syslog.conf (rsyslog does), so it can seem a little complicated at first glance, but for complex or advanced logging setups (especially at a central loghost), Syslog-NG is an excellent choice.

Improve this answer
3
  • Thanks for checking that. I am also blocking the port via IPTables, but I wish they would fix it so that it does not even listen to that port when it does not have to (having a service listening when it is not needed violates server hardening standards).
    – Jim
    Apr 2, 2012 at 20:34
  • Absolutely. Unfortunately, after this length of time, and with sysklogd no longer being the default syslog daemon with RHEL 6.x, I have a feeling they're just going to ignore it until it goes away. That reminds me, rsyslog (or syslog-ng) would also be a viable option to resolve this. I'll update my answer to include mention of that, too.
    – Christopher Cashell
    Apr 2, 2012 at 20:58
  • 1
    rsyslog is better any way - you can fine-tune it much better than the standard syslog.
    – Nils
    Apr 2, 2012 at 21:15
1

This is pretty odd. I tested on my Centos 5.8 VM and don't see the problem you're describing. Adding -r adds the udp port and removing -r and restarting removes it. I have sysklogd-1.4.1-46.el5 installed if that helps.

Improve this answer
2
  • I have the same version (sysklogd-1.4.1-46.el5).
    – Jim
    Mar 30, 2012 at 14:59
  • Are you logging to a central syslog server? I am, and I just tried turning that off (removing the ". @192.168.1.22" line from syslog.conf), and it no longer listens on 514. But it should not listen to 514 - just send entries to the remote server! Also, using "lsof -i UDP", I can see that 514 is opened for read & write, if that matters.
    – Jim
    Mar 30, 2012 at 15:03
0

GNU syslogd (AKA sysklogd) is part of inetutils. I've linked to the source to show the conditions under which it binds to a UDP port:

  • head circa 3/2012 (based on 1.9.1). It's checking AcceptRemote, which is only set when syslogd is invoked with -r.

  • v1.6 from 2007. In addition to the -r/AcceptRemote case above, it will also bind when NoForward is not set. That is the default. I suspect that you're running this version or something like it. The options parser only has a long option to disable it, --no-forward, and obviously that breaks functionality you need.

And finally, buried way down here, I'll provide the real answer: any time spent configuring GNU syslogd would be better spent replacing it with something else. Happy Easter :-)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .