[Logwatch] logwatch is DOA - strace -f output included from test.pl

MrC lists-logwatch at cappella.us
Thu Oct 2 15:27:13 MST 2008


Dale Morin wrote:
>>
>> How many actual entries are in that directory including . and .. ?
> 
> There are 94 entries in /usr/share/logwatch/default.conf/services
> including . and .. (by running "ls -la | wc -l").
> 
> Hmmmmm.  94 vs 93?  That's interesting.  Does gendents include . and ..
> in the count of files?  There are no dirs in the services directory,
> just files.

Yes, . and .. are just directory entries, and hence are returned.
Compare the list of returned entries from the stat64 calls to the actual
contents.  It would be interesting to see which one is missing.

The 93 entries read consumed 3280 bytes, but the buffer was large enough
for 4096 bytes, so the last entry most assuredly would have fit, unless
the last entry was corrupt and therefore exceeded the buffer space.
Hence, the second getdent64() call.


> 
>> This could be caused by a corrupted file system.  Have you force fsck'd
>> that file system?
> 
> No, it's a relatively new box, has been running less a month or so.  The
> odds of a corrupted filesystem on a lightly loaded dns server are slim,
> but they are not zero.  I can if needed.

Does the box have ECM memory?  Bit flips happen, and the load of the box
does not influence stray gamma particles from the sun.  The only way to
know for sure is to force a check.

> 
>> If clean, it could also be a bug somewhere in the getdents64() call path
>> down to the file system-specific code.  There have been numerous reports
>> over the years of getdnents* hangs.  Which file system type is
>> /usr/share/logwatch/default.conf/services ?
> 
> It is ext3.
> 

Ok, good to know.  Nobody will entertain looking at a bug possibility
without the prerequisite steps such as fsck having been accomplished, so
its worth doing sooner rather than later.

> Thanks.
> 
> 



More information about the Logwatch mailing list