Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 154110 - Syslogd fails to open log file outside of /var/log
Syslogd fails to open log file outside of /var/log
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sysklogd (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-04-07 08:50 EDT by Trond H. Amundsen
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-07 12:40:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Trond H. Amundsen 2005-04-07 08:50:31 EDT
Description of problem:

Syslogd fails to open a log file that resides outside of /var/log on 64 bit
systems. It works fine on ia32. For example, if /etc/syslog.conf has the
following contents:

  # cat /etc/syslog.conf
    *.debug         /all.log

The syslogd process fails to open /all.log on startup:

  # strace -f /sbin/syslogd -d
    write(1, "filename: /all.log\n", 19)    = 19
    open("/all.log", O_WRONLY|O_APPEND|O_CREAT|O_NOCTTY, 0644) = -1 EACCES
(Permission denied)
    write(1, "Error opening log file: /all.log"..., 33) = 33

The file /all.log is just an example. Syslogd fails to open any file that is
outside of /var/log or its subdirectories. If one copies /sbin/syslogd from an
ia32/rhel4 or x86_64/rhel3 system and uses that instead, it works fine.

When using using the ia32/rhel4 version, it works as expected:

  # strace -f /tmp/syslogd.fangorn -d
    write(1, "filename: /all.log\n", 19filename: /all.log)    = 19
    open("/all.log", O_WRONLY|O_APPEND|O_CREAT|O_NOCTTY|0x8000, 0644) = 4
    ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffffaab8) = -1 ENOTTY
(Inappropriate ioctl for device)

And also when using the x86_64/rhel3 version:

  # strace -f /tmp/syslogd.diger -d
    write(1, "filename: /all.log\n", 19filename: /all.log)    = 19
    open("/all.log", O_WRONLY|O_APPEND|O_CREAT|O_NOCTTY, 0644) = 4
    ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fbfffcf00) = -1 ENOTTY
(Inappropriate ioctl for device)

Syslog facilities doesn't matter, I get the same results with e.g.
'logger -p news.err foo'. Conclusion is that syslogd on x86_64/rhel4 only works
on /var/log (or any subdirectory thereof), while syslogd from other rhel
versions works regardless of where the logfile is located.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Spesify a log file outside of /var/log in /etc/syslog.conf
2. (Re)start syslog
3. Monitor the outcome..
Actual results:
Explained above.

Expected results:
Syslogd should work regardless of logfile placement.

Additional info:
Comment 1 Jason Vas Dias 2005-04-07 12:09:51 EDT
Do you have SELinux enabled ?
$ getenforce
'Enforcing' and not 'Permissive' or 'Disabled' ?

I think what is happening is that SELinux is preventing syslogd from creating
the log file, because it is not labelled with the 'var_log_t' file context.  
Comment 2 Trond H. Amundsen 2005-04-07 12:40:49 EDT
Bloody hell.. I didn't think of that, haven't had time to investigate SELinux yet.
I wasn't even aware that SELinux was enabled as default. Thanks for the quick
response, Jason. You saved the day (and our new NNTP server) :)

I'm resolving this bug as NOTABUG.

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