[CentOS] logs such as messages, boot.log, and kernel contained 0 size

Jay Leafey jay.leafey at mindless.com
Thu Feb 12 04:40:30 UTC 2009


Frank Ling wrote:
> Hi,
> 
> My both CentOS 5 servers have logging problems. Logs such as messages, 
> boot.log, kernel, spooler, and tallylog in /var/log directory are all 0 
> size.
> 
> The kernel is:  Linux 2.6.18-92.1.22.el5 #1 SMP.
> 
> Since the /var/log/messages contained no information it would be 
> impossible to troubleshoot the problem.
> 
> I am very sure both systems have not been hacked by others.
> 
> Sincerely,
> 
> Frank Ling
> --------------------------------------------------------------------------
> -rw-------  1 root         root          0 Feb  8 04:02 messages
> -rw-------  1 root         root          0 Feb  3 11:04 messages.1
> -rw-------  1 root         root          0 Jan 25 04:02 messages.3
> -rw-------  1 root         root          0 Jan 11 04:03 messages.4
> -rw-------  1 root         root         10 Dec 27 13:00 messages.offset
> 
> -rwx------  1 root         root          0 Feb 11 19:12 kernel
> -rwx------  1 root         root          0 Feb 11 16:53 kernel.1
> -rwx------  1 root         root          0 Jan 25 04:02 kernel.3
> -rwx------  1 root         root          0 Jan 11 04:03 kernel.4
> 
> -rw-------  1 root         root          0 Feb  8 04:02 spooler
> -rw-------  1 root         root          0 Feb  3 07:51 spooler.1
> -rw-------  1 root         root          0 Jan 25 04:02 spooler.3
> -rw-------  1 root         root          0 Jan 11 04:03 spooler.4
> 
> -rw-------  1 root         root          0 Jun 24  2008 tallylog
> --------------------------------------------------------------------------
> 

I've had something similar happen a couple of times after an update.  In 
my case the /etc/services file got it's security context clobbered when 
some package tried to update it's contents.  When logrotate ran, the 
syslog daemon couldn't open /etc/services because of the error and I 
ended up with a bunch of empty log files.

The quickest way to check for this is the command:

     restorecon -v /etc/services

If nothing prints out in response, that's not the problem.  If it DOES, 
that might explain it.  I have been checking the contexts occasionally 
to try and trap exactly when it happens.  I use:

     restorecon -R -n -v /etc

which walks through the entire /etc tree looking for contexts to change 
but just reports any exceptions.

Just a thought!
-- 
Jay Leafey - Memphis, TN
jay.leafey at mindless.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5566 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20090211/3a9a6135/attachment.bin>


More information about the CentOS mailing list