rsyslog fails to create tcp socket.

Bug #789174 reported by dennybaa on 2011-05-27
This bug affects 63 people
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)

Bug Description

Binary package hint: rsyslog

My package:
ii rsyslog 4.6.4-2ubuntu4

The thing is that when starting rsyslog first drop privileges and then tries to create socket and more. This seems to be a bug, because the same configuration works fine on 10.04. Configuration is attached.

rsyslog output:
May 27 18:37:55 ubuntu01 kernel: imklog 4.6.4, log source = /proc/kmsg started.
May 27 18:37:55 ubuntu01 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="5547" x-info=""] (re)start
May 27 18:37:55 ubuntu01 rsyslogd: rsyslogd's groupid changed to 103
May 27 18:37:55 ubuntu01 rsyslogd: rsyslogd's userid changed to 101
May 27 18:37:55 ubuntu01 rsyslogd-2039: Could no open output pipe '/dev/xconsole' [try ]
May 27 18:37:55 ubuntu01 rsyslogd-2077: Could not create tcp listener, ignoring port 514. [try ]

Jiri Hoogeveen (wica128) wrote :


I have the same problem.
Because rsyslog drops privileges to syslog, and the required port is 514, which can only be used by a process running with root privileges (every port below 1025)

workaround is a port above 1024

Jiri Hoogeveen (wica128) wrote :

And a other problem with Drop Privileges.
If you use $template ApacheRemoteCustom,"/some/path/%HOSTNAME%.log"
rsyslog can create the file, but not write to it.
To make this possible you have to change /etc/rsyslog.conf

$PrivDropToGroup syslog
$PrivDropToGroup adm

Changed in rsyslog (Ubuntu):
status: New → Confirmed

has anyone figured out a workaround for this? Maybe adding a sleep somewhere might help?

Jiri Hoogeveen (wica128) wrote :

@phillyclaude Sleep will not solve the issue, the only workaround is in my reaction on 2011-06-09

Mick Pollard (aussielunix) wrote :

Hacky workaround but if you have some devices that can only talk to port 514
drop privs and listen on a high port. (10514)

# redirect traffic to high port with iptables
/sbin/iptables -t nat -A PREROUTING -j REDIRECT -p udp --destination-port 514 --to-ports 10514

waleed (waleedsaud) wrote :

I changed the port from 514 to 1025(bigger that 1024 ) in /etc/rsyslog.conf file in the TCP part nad this worked.
is this a wrong solution and if it is ok why don't change the port until the bug fixed in rsyslog?

Kevin Pattison (kevpatts) wrote :

This worked for me also, port 1025.

Ryan Kather (rkather) wrote :

I am also seeing this bug, and would like to see this resolved outside of the workaround to a port higher than 1024. It seems to be a problem relating to binding the TCP port later after it has already dropped permissions. My rsyslog.conf file (attached) is using the $PrivDropToUser syslog and $PrivDropToGroup syslog directives.

Ubuntu Process Info
syslog 29622 0.0 0.3 262268 3404 ? Sl Jun12 7:33 rsyslogd -c5

My centos/rhel systems do not exhibit this bug, but after looking it seems they are running rsyslog as root by default.

RHEL Process Info
root 2347 2.6 0.0 416916 2088 ? Sl Jun20 2236:08 /sbin/rsyslogd -i /var/run/ -c 4

Package Version: rsyslog 5.8.6-1ubuntu8

Ryan Kather (rkather) wrote :

The example server configuration listening on TCP 514 that fails.

Scott Moser (smoser) wrote :

Ryan, the pipermail link above is to upstream discussion about this. Unless there is something upstream newer than that 2 year old information, your options are:
a.) run rsyslog as root by removing the $PrivDropToUser and $PrivDropToGroup options, or possibly overriding them in /etc/resolv.conf.d/ files (i'm not sure if this is possible or not).
b.) use the 'Sleep' work around suggested on the thread (git commit [1]).
c.) listen on a port > 1024
d.) pay upstream for 2 weeks work to get the fix done correctly.


Ryan Kather (rkather) wrote :


Thank you for the information. In my initial browse I'm not seeing anything updated regarding improved listener behavior, so I think that sleep workaround stands. I'm definitely looking into that over either changing the port or running as root (which I'd like to avoid if at all possible).

I'll solicit my work to see how they feel on reimbursement for the proper bug fix to address the privilege race condition. Chances are they'll air on the side of cheap and stick with the ugly, unforunately. Thank you again for your response.


tags: added: precise
RedShift (redshift-gmx) wrote :

Can't quite believe it, centralized logging on standard 514 is not possible while not running as root or without paying 2 weeks of upstream redesign of a piece of code which could have been done correctly the first time?

Going to reconsider syslog-ng...

THCTLO (thctlo) wrote :

This problem is still here..

for "Server LTS " this is bad..

i tried also the raring version, and...

Mar 5 21:37:09 oms kernel: imklog 5.8.11, log source = /proc/kmsg started.
Mar 5 21:37:09 oms rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="25002" x-info=""] start
Mar 5 21:37:09 oms rsyslogd: rsyslogd's userid changed to 101
Mar 5 21:37:09 oms rsyslogd-2077: Could not create tcp listener, ignoring port 514. [try ]

Still there... :-(

kapetr (kapetr) wrote :

I thing, it is a Bug. Normal for suid progs IMHO is: make thing which need root privileges (e.g. bind to port below 1024) and then drop privileges., or not ?

marc (malerisch) wrote :

an easy fix, but it almost takes 2 years :((( What horrible. But right now it is running on port 514 . Thanks Rainer...

Václav Haisman (vzeman79) wrote :

I am experiencing this on Raring as well.

tags: added: quantal raring
Nick (kg6nmp) wrote :

Also seeing this in Raring. Was hoping to use this server for syslog, this is pretty disappointing.

Jiri Hoogeveen (wica128) wrote :

also fixed in 14.04, YEaaah :)

Simon Déziel (sdeziel) wrote :

Marking as Fix Released based on comment #20, thanks.

Changed in rsyslog (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers