Why:
logrotate 3.8+ refuses to rotate files in world/group-writable parent
directories unless a su directive is present. su root root causes
"Operation not permitted" in CI running as non-root (uid 1000).
Impact:
All five imfile-logrotate* tests now pass with logrotate 3.8+ in root
and non-root environments.
Before/After:
Before: Tests timeout or fail under non-root CI with logrotate 3.8+.
After: Dynamic su uses current user/group; rotation succeeds in CI.
Technical Overview:
Add su '"$(id -un)"' '"$(id -gn)"' to each test's logrotate config block.
This satisfies logrotate's security check without switching to root.
Affected: imfile-logrotate.sh, imfile-logrotate-async.sh,
imfile-logrotate-copytruncate.sh, imfile-logrotate-multiple.sh,
imfile-logrotate-nocopytruncate.sh.
State file handling was invalid. When a file was moved and re-created
rsyslog could use the file_id if the new file to write the old files'
state file. This could make the file reader stuck until it reached the
previous offset. Depending on file sizes this could never happen AND
would cause large message loss. This situation was timing dependent
(a race) and most frequently occurred under log rotation. In polling
mode the bug was less likely, but could also occur.
closes: https://github.com/rsyslog/rsyslog/issues/3465
closes: https://github.com/rsyslog/rsyslog/issues/3468
