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
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 syslogd. pid -c 4
root 2347 2.6 0.0 416916 2088 ? Sl Jun20 2236:08 /sbin/rsyslogd -i /var/run/
Package Version: rsyslog 5.8.6-1ubuntu8