rsyslog fails to create tcp socket.

Bug #789174 reported by dennybaa
306
This bug affects 63 people
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)
Fix Released
Undecided
Unassigned

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="http://www.rsyslog.com"] (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 http://www.rsyslog.com/e/2039 ]
May 27 18:37:55 ubuntu01 rsyslogd-2077: Could not create tcp listener, ignoring port 514. [try http://www.rsyslog.com/e/2077 ]

Revision history for this message
Jiri Hoogeveen (wica128) wrote :

Hi,

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)

http://lists.adiscon.net/pipermail/rsyslog/2010-April/011700.html

workaround is a port above 1024

Revision history for this message
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
To
$PrivDropToGroup adm

Changed in rsyslog (Ubuntu):
status: New → Confirmed
Revision history for this message
phillyclaude (claude-claudeschrader) wrote :

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

Revision history for this message
Jiri Hoogeveen (wica128) wrote :

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

Revision history for this message
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

Revision history for this message
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?

Revision history for this message
Kevin Pattison (kevpatts) wrote :

This worked for me also, port 1025.

Revision history for this message
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/syslogd.pid -c 4

Package Version: rsyslog 5.8.6-1ubuntu8

Revision history for this message
Ryan Kather (rkather) wrote :

The example server configuration listening on TCP 514 that fails.

Revision history for this message
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.

[1] http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a002ab4

Revision history for this message
Ryan Kather (rkather) wrote :

Scott,

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.

Ryan

tags: added: precise
Revision history for this message
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...

Revision history for this message
THCTLO (thctlo) wrote :

This problem is still here..

for "Server LTS " this is bad..

i tried also the raring version, and...
GOOD WORK !!

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="http://www.rsyslog.com"] 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 http://www.rsyslog.com/e/2077 ]

Still there... :-(

Revision history for this message
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 ?

Revision history for this message
THCTLO (thctlo) wrote :
Revision history for this message
marc (malerisch) wrote :

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

Revision history for this message
Václav Haisman (vzeman79) wrote :

I am experiencing this on Raring as well.

tags: added: quantal raring
Revision history for this message
Nick (kg6nmp) wrote :

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

Revision history for this message
Jiri Hoogeveen (wica128) wrote :

also fixed in 14.04, YEaaah :)

Revision history for this message
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  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.