From my PoV, this is a problem that stems back to either the config provided and/or other packages.
Ubuntu makes rsyslog drop privileges. That's fine, though has some documented quirks until v6. Most importantly for this bug, files are opened before dropping privs. Nevertheless, files are created with proper owners *iff* the owner is properly configured. Then, privs are dropped. If the file owner is wrong, rsyslog can close files on HUP, but obviously not reopen it.
The described problem happens under the following circumstances:
(a) rsyslog.conf does not corretly contain file owner directives, so files are in the initial phase created with wrong user
(b) a third party package (usually logrotate) re-creates the files with an invalid owner or permissions
For both problems bug reports exists here. In rsyslog v6, I have finally refactored the code so that files are opened after priv drop. With the current state of affairs, this means that rsyslog v6 on Ubuntu will probably never start. So I really think it would be time to clean-up package dependencies or run rsyslog as root if the source of changing file permissions can not be found.
From my PoV, this is a problem that stems back to either the config provided and/or other packages.
Ubuntu makes rsyslog drop privileges. That's fine, though has some documented quirks until v6. Most importantly for this bug, files are opened before dropping privs. Nevertheless, files are created with proper owners *iff* the owner is properly configured. Then, privs are dropped. If the file owner is wrong, rsyslog can close files on HUP, but obviously not reopen it.
The described problem happens under the following circumstances:
(a) rsyslog.conf does not corretly contain file owner directives, so files are in the initial phase created with wrong user
(b) a third party package (usually logrotate) re-creates the files with an invalid owner or permissions
For both problems bug reports exists here. In rsyslog v6, I have finally refactored the code so that files are opened after priv drop. With the current state of affairs, this means that rsyslog v6 on Ubuntu will probably never start. So I really think it would be time to clean-up package dependencies or run rsyslog as root if the source of changing file permissions can not be found.