Comment # 6 on bug 1008107 from
(In reply to David Taylor from comment #4)
> I have not been able to reproduce the problem.  
> 
> I left the machine as-is for over a month to see if it would happen again (I
> took it out of production use and let it sit with a different IP address). 

If this was easy to reproduce I think we would have had much more reports and
have this fixed. Since this seems to have been a log rotation caused issue I
think the thing to do is focus on intensifying log rotation possible mishaps.

> After running cleanly during that period of time, I patched it 

Stick to one kernel at a time otherwise we cannot identify or fix things.

> and put it
> back into service.  The problem has not cropped up since then.  To be
> honest, I'm not entirely certain what led up to that failure as it happened
> at night during a quiet period.  The only thing going on during that time
> frame (for the most part) was logs being rolled by logrotate and logwatch
> running reports as those run at 1AM.

:) Sounds like one thing to test against as I indicated in my last comment.

> To correct the mounting /var issue, I had to flush the metadata.  The fsck
> hung otherwise.  If there was something funky in it, it was destroyed in
> attempting to get the volume back.

Oh well.

> I have the before and after syslog files saved off if they are of any use,
> but otherwise I'm afraid I don't have much else I can provide at this point.

I think I've given enough info in to what we can do with what we have. If you
are not up to try real hard to reproduce I'm afraid this bug should be closed
as we just don't have enough lead to help address this. Will make a note to try
to draw up a program to tests against this in the future.


You are receiving this mail because: