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/servicesrestorecon 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}.My actual hunch about this problem after thinking about the above is that it is# service syslog restart And now /var/log/messages is being updated like normal.
really a udev problem. My suspicion would be that udev is not making a "devnode" 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'sand 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.
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 beSince the vmware-server install is from their rpm package, I am going to post there:http://www.vmware.com/community/thread.jspa?messageID=617291
"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/
