Re: Linux problem resolution.

[Fritz Hayes <fhayes@xxxxxxxxxxxxx>]

Also, look at the dmesg log file in the same location (tail 
/var/log/dmesg -n 500).  It will provide the bootup details and help to 
id what might have broken.

Fritz Hayes


David Gibbs wrote:
> rob@xxxxxxxxx wrote:
> > Now, back to my problem.  This morning the Linux server was locked up 
> > tighter than a drum.  No keystrokes, mouse, etc would get a response. Suse 
> > Linux.  The network guy really is not aware of how to look for problem 
> > resolution in Linux to handle this.  For example in Windows you can 
> > actually look up codes from the BSOD, look at log files, etc.  How does 
> > one get started down this path in Linux?  Any RTFM is acceptable if you 
> > supply a good manual.
>
> After you reboot the system, check the messages log (often found at
> /var/log/messages) ... you are probably looking for a 'kernel panic'.
> Kernel panics are usually caused by hardware failures.  In my experience
> they are usually caused by memory or motherboard problems, although I've
> had serious disk problems cause panics also.
>
> I'm guessing that you run the Linux system with a GUI active ...
> unfortunately, when the kernel panics it isn't always able to write the
> last log entry out to disk before the system freezes up completely.
> This is one of the primary reasons I never run a GUI on a server.  The
> kernel panic information is always sent to the console, so if the
> information isn't in the log file, I can always look at the screen.
>
> If it indeed a kernel panic, and you can get the codes that are
> reported, there is a tool available to parse the codes ... it's called
> 'parsemce'.  I've posted a copy of the source to
> http://code.midrange.com/index.php?id=ebe1403bbd.
>
> david