Comment 11 for bug 940030

Revision history for this message
TJ (tj) wrote :

This seems to be caused by the logrotate configuration for rsyslog using the system dbus-daemon. Here's the representative example for "/var/log/syslog":

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

The 'postrotate' script command "reload" is a symlink to "/usr/sbin/initctl"

initctl uses the system dbus to communicate:

# ps -C dbus-daemon -O user,group --noheader | awk '{cmd="getent passwd " $2; cmd | getline user; cmd="getent group " $3; cmd | getline group; printf "PID: %d USER: %s GROUP: %s CMD: %s\n", $1, user, group, $7}'

PID: 2617 USER: messagebus:x:102:105::/var/run/dbus:/bin/false GROUP: messagebus:x:105: CMD: dbus-daemon

# ps -C rsyslogd -O user,group
  PID USER GROUP S TTY TIME COMMAND
25970 syslog syslog S ? 00:00:00 rsyslogd -c5

I'm not quite sure how that causes ownership of the files to change since the 'rsyslogd' process is running as "syslog:syslog" and its configuration sets FileOwner:FileGroup to "syslog:adm" so the HUP should just not interfere with the ownership when it recreates the log file.

It seems FileGroup ("adm") survives but FileOwner is the dbus-daemon UID.