One of the forum mods (and likely of other official roles) over at the rsyslog.com knowledge-base suggests in this relatively recent thread:
http://kb.monitorware.com/local-file-logging-stopped-t11391.html .. that this condition is likely reflecting a per-distribution, implementation-specific problem related to the configuration options $PrivDropToUser [user] $PrivDropToGroup [group] For rsyslog 4.7.x, and 5.3.x to 5.8.x, their docs suggest there is a built-in workaround that is likely effective in many cases, '$omfileForceChown which can be added to the rsyslog.conf: $omfileForceChown on http://www.rsyslog.com/doc/rsconf1_omfileforcechown.html Note this workaround is not available in subsequent versions of rsyslog (eg upstream ppa's such as the one they host at rsyslog.com). To me, it seems that this process could be simplified by creating the replacement file before removing/transitioning away from/stashing the old log file and then just guessing at the permissions. This should let correct/desired and specific ownership and permission masks be copied/applied with the least complication instead of relying on suid, sguid, configuration global generic/universal masks, or other sometimes tricky or perilous techniques. A possible caveat is that the existing log file that rsyslog is writing to, must also allow reading in order to get necessary security meta-information. Ideally, the configuration option would only be a fall-through option if the log didn't exist in the first place (essentially a stricter take on an independent service facility provider umask). By utilizing either "cp --attributes-only" from a recent core-utils update (16/17) before remove/stash, this particular issue might be permanently worked around.. or by using 'stat' with formatting options to read ownership and permissions before remove/stash, such as: cp --attributes-only "$log_to_stash" "$log_to_activate" rotate_cmd "$log_to_stash" "$log_to_activate" or elevate_up touch "$log_to_activate" chmod `stat --printf="%a" $log_to_stash` "$log_to_activate" chown `stat --printf="%U:%G" $log_to_stash` "$log_to_activate" rotate_cmd "$log_to_stash" "$log_to_activate" drop_back_cmd Note that "cp --attributes-only" is a fairly recent addition to core-utils, and I am sure among many other places, discussed briefly here: https://bugzilla.redhat.com/show_bug.cgi?id=811746 'cp --attributes-only' does not seem to rely on the same underlying behavior of chown and currently seems able to set target meta ownership information even if executor is not of elevated privilege (as it is apparently and relatively new, I am not sure what the intended behavior is in this case). Likely it is intentionally permitted as no underlying data is coming with the file. ** Bug watch added: Red Hat Bugzilla #811746 https://bugzilla.redhat.com/show_bug.cgi?id=811746 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/940030 Title: rsyslog stops working after logrotate until restarted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/940030/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
