David Timms wrote:
Joel Gomberg wrote:
# ls -lZ /etc/serv*
-rw-r--r-- root root user_u:object_r:rpm_script_tmp_t /etc/services
# restorecon -v /etc/services
restorecon reset /etc/services context
user_u:object_r:rpm_script_tmp_t:s0->system_u:object_r:etc_t:s0
# ls -lZ /etc/ser*
-rw-r--r-- root root system_u:object_r:etc_t /etc/services
/usr/sbin/getenforce
replies:
Permissive
That is, I run with selinux in "Permissive" so it should not be blocking
access even
if a context is messed up. I should see some log entries, which I
don't. Currently
running under kernel 2.6.20-1.2925.fc6 which didn't show the syslog
problem on
bootup. I will try again under 2.6.20-1.2933.fc6 later this week.
So the se context was incorrect. It didn't seem to start logging
immediately {ie on an ssh login}.
# service syslog restart
And now /var/log/messages is being updated like normal.
My actual hunch about this problem after thinking about the above is
that it is
really a udev problem. My suspicion would be that udev is not making a "dev
node" required for syslog to start "soon enough" in the boot. This
would mean
that a "service syslog restart" AFTER booting is completed would always
restore syslogging, but after another reboot, syslog MIGHT (depending on
some race condition) again cause syslog to fail, requiring another "service
syslog restart" to restore logging.
Please observe whether that is an issue after your next reboot.
The udev people have created a lot of various kinds of race conditions
in their
effort to speed up rebooting by allowing udev to run multiple threads to
do things in parallel. I am actually considering investigating where the
"knob" is to turn that off. I don't reboot the machine in question often
enough that I worry about booting time very much. (Besides, having learned
to be a coffee drinker when dealing with booting the computers of the 60's
and 70's, I usually have a cup of coffee nearby during boots. :0) A
laptop or some
such that gets booted often is where booting time is an issue.
Thanks Joel :)
John: Do you have vmware {of some flavour} installed ? (I guess Joel's
hunch would apply to any of their apps that use an .pl install script).
No VMWare on this machine. Besides, as noted above, selinux is running
"Permissive"
so selinux access denials should not be a problem.
Since the vmware-server install is from their rpm package, I am going
to post there:
http://www.vmware.com/community/thread.jspa?messageID=617291
See my comment above about udev race conditions. I would be interested
in an
observation of whether "service syslog restart" is required after the
next boot. You
would have to watch /var/log/messages a little closer since it would no
longer be
"0 bytes" at that point and you might miss that logging went away again.
If it is a udev race, note that it may affect some machines, not others
(mine is a
dual core) and might affect some boots, not others, if the race
condition is "close".
DaveT.
John DeDourek
http://www.cs.unb.ca/~dedourek/
