syslogd running but not logging on boot
I recently upgraded the Perl implementation (in addition to a number of other components) on a RHEL 4 system. I also made modifications to the /etc/syslog.conf and /etc/sysconfig/syslog files. On a reboot, boot the syslogd and klogd daemon come up as evidenced here:
Code:
$ ps ax | grep logd | grep -v mini | grep -v grep If I log in as root and stop the daemon via Code:
$ /etc/init.d/syslog stop Code:
$ syslogd -m 0 -x -r Code:
# Log all kernel messages to the console. Code:
# Options to syslogd Thanks, DT |
Quote:
Time to start eliminating possibilities to get to the root cause. If reverting the changes and restarting the syslog service does not correct the problem, then it's time to review the packages you most recently updated. They should have been recorded to /var/log/up2date (assuming that logging is working). Also, what does $ /usr/sbin/getenforce show? |
Quote:
Logging to /var/log/up2date ends at the same time logging to everything else does. I believe that this coincides with the time that I instealled Perl. To clarify, I installed Perl 5.8.9 from source as opposed to from up2date. I need a version of Perl that is 5.8.8 or higher for one of the custom packages I am running and I couldn't figure out how to get a version higher than 5.8.5 from up2date. I also reinitialized VMware Server and made modifications to the compiled Perl path so that VMware server would load 5.8.9 perl modules instead of 5.8.5. Code:
$ /usr/sbin/getenforce |
Quote:
At the very, very least, use some form of sloppy version control prior to editing, e.g.: # cp -p /etc/foo.conf /etc/foo.conf.20090301 <-- should reflect today's date You need to be able to roll back changes without thinking too hard about them. Quote:
The problem with diverging from the RHN (with your own custom packages or source installations) is you open a can of worms that makes it significantly more likely you're going to break something. Especially with a crucial app like perl. If you absolutely require a newer version of perl, it may be necessary to start planning an upgrade to RHEL5 (or check your other RHN channels for RHEL4 to see if it happens to be available). Quote:
# restorecon -R /var/log Then run the exact same command on the directory you've installed perl to. Finally, restart the syslog service. Problem solved? If not, you could also boot with selinux disabled to try to eliminate that as a possible cause. |
Thanks,
Quote:
|
See the manpages for restorecon(8). With that command you'll be recursively restoring default security contexts for the directory specified. It should not break anything unless you've been playing around with selinux policies.
|
Oh yeah, man pages... Duh!
Thanks, I will try that out as soon as I get in tomorrow. |
Thanks!
restorecon didn't fix it but disabling SE Linux did. I'll have to figure out what SE Linux settings I messed up with the Perl upgrade but I'm now good to go.
Thanks for you time and patience, DT |
One thing you could try is putting selinux in permissive mode. Then watch /var/log/messages for entries of the form "kernel: audit ..."
This should give you clues about what exactly is being denied. |
Cool, thanks, I'll look into as soon as I get a chance.
Cheers, DT |
All times are GMT -5. The time now is 06:45 PM. |