Bug 218701 - Logrotate causes syslog to fail if /tmp is mounted noexec
Logrotate causes syslog to fail if /tmp is mounted noexec
Status: CLOSED DUPLICATE of bug 156594
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: logrotate (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-06 16:05 EST by Matt Whitted
Modified: 2015-01-07 19:15 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-06 16:58:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Whitted 2006-12-06 16:05:47 EST
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.
Comment 1 Peter Vrabec 2006-12-06 16:58:53 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.