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): sysklogd-1.4.1-26_EL How reproducible: Always 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:
Do you have SELinux enabled ? ie: $ getenforce reports '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.
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.