/var/log/messages is not getting new data.

[John DeDourek]

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/