empty system logs 1

[oceandeep]

Hi,

I have one RHEL 4 server, but I found the boot.log, message.log and secure log files are always empty. The syslog.conf looks fine as I compared it with a working machine. syslogd is also running. Can anybody please help?

Thanks!

Below is the syslog.conf file:

********************************************
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* -/var/log/maillog


# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log
********************************************

 

[ZaSter]

oceandeep,

What do you get from running the following command:

service syslog status

 

[oceandeep]

it says both processes are running...

**************************
syslogd (pid 7012) is running...
klogd (pid 7016) is running...
**************************

But I spotted there are a lot of error messages appeared on console:

***************************************
audit(1178180818.578:77): avc: denied { read } for pid=7012 comm="syslogd" name="log" dev=dm-0 ino=422681 scontext=root:system_r:syslogd_t tcontext=user_ubject_r:var_t tclass=lnk_file
syslogd: /var/log/secure: Permission denied
audit(1178180818.578:78): avc: denied { read } for pid=7012 comm="syslogd" name="log" dev=dm-0 ino=422681 scontext=root:system_r:syslogd_t tcontext=user_ubject_r:var_t tclass=lnk_file
syslogd: /var/log/maillog: Permission denied
audit(1178180818.578:79): avc: denied { read } for pid=7012 comm="syslogd" name="log" dev=dm-0 ino=422681 scontext=root:system_r:syslogd_t tcontext=user_ubject_r:var_t tclass=lnk_file
syslogd: /var/log/cron: Permission denied
audit(1178180818.579:80): avc: denied { read } for pid=7012 comm="syslogd" name="log" dev=dm-0 ino=422681 scontext=root:system_r:syslogd_t tcontext=user_ubject_r:var_t tclass=lnk_file
syslogd: /var/log/spooler: Permission denied
audit(1178180818.579:81): avc: denied { read } for pid=7012 comm="syslogd" name="log" dev=dm-0 ino=422681 scontext=root:system_r:syslogd_t tcontext=user_ubject_r:var_t tclass=lnk_file
syslogd: /var/log/boot.log: Permission denied
~
***************************************

Any ideas?

Thanks!

 

[pansophic]

What are the permissions for your log files? And the /var/log directory?


pansophic

 

[oceandeep]

****************************
-rw-r----- 1 root root 540 May 3 21:17 acpid
-rw-r--r-- 1 root root 22600 May 3 21:17 boot.log
-rw-r--r-- 1 root root 50211 May 3 21:25 cron
-rw-r--r-- 1 root root 17207 May 3 21:17 dmesg
-r-------- 1 root root 146584 May 3 21:19 lastlog
-rw-r--r-- 1 root root 3350 May 3 21:17 maillog
-rw-r--r-- 1 root root 157367 May 3 21:22 messages
-rw-r--r-- 1 root root 20340 May 3 04:02 rpmpkgs
-rw-r--r-- 1 root root 15982 May 3 21:19 secure
-rw-r--r-- 1 root root 0 May 2 18:58 spooler
-rw-rw-r-- 1 root utmp 91776 May 3 21:19 wtmp
-rw-r--r-- 1 root root 45629 May 3 19:21 Xorg.0.log
-rw-r--r-- 1 root root 47416 May 3 19:19 Xorg.0.log.old
****************************

It looks alright. And if I just started syslogd directly from /sbin/syslogd, everything seems to be fine; but if started it from /etc/init.d/syslog, then I got the problem.

 

[pansophic]

It has to be an environment problem when starting syslogd from init. Check the options in the script /etc/init.d/syslog to see if it is being started (or an environment variable is being set) as another user (other than root). I can't imagine what else it could be.


pansophic

 

[ZaSter]

oceandeep,

I've a hunch that this an SElinux (Security Enhanced Linux) problem. SElinux gets upset if files in /etc/ are modified and not "blessed" by the "restorecon" command.

If this is the case, then running the following command will solve the problem:

/sbin/restorecon -R /etc/

That help?
--
ZaSter

 

[oceandeep]

Thanks ZaSter! It is related to selinux, but it is still not working after I ran your command. So I have to disable selinux for now.