Description of problem: Version-Release number of selected component (if applicable): logrotate-3.7.1-5.RHEL4 sysklogd-1.4.1-26_EL How reproducible: Very Steps to Reproduce: # mount -o remount,noexec /tmp # logrotate -f /etc/logrotate.conf Actual results: Logrotate -f will output: error: error running shared postrotate script for /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron lsof shows that syslogd is "hung" on the rotated logfiles: # lsof |grep messages syslogd 2430 root 2w REG 253,4 505 211351 /var/log/messages.1 (deleted) The new, empty messages file will remain empty until syslogd is manually restarted. Expected results: Logrotate should have some type of facility to handle security enhancements such as mounting /tmp noexec, such as an alternative tmp directory. Additional info: The postrotate script seems to be the culprit, apparently logrotate writes an actual script and then executes it? The syslog file in /etc/logrotate.d is stock, but here is the contents for completeness: # cat /etc/logrotate.d/syslog /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron { sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true endscript } Additionally, it is worth noting that we have a number of ES3 systems in production. The above behavior is NOT reproducible on the ES3 platform, where a noexec'ed /tmp does not seem to cause any logrotate issues. This behavior also seems to be documented here: http://forums.fedoraforum.org/archive/index.php/t-22359.html Solution in above forum was to remove the noexec restriction on /tmp, which is not desirable in our situation.
It's going to be fixed with logrotate-3.7.1-6.RHEL4 in next update. *** This bug has been marked as a duplicate of 156594 ***