[PLUG] Devise a remote log

Mike C. mconnors1 at gmail.com
Fri Jul 10 02:51:03 UTC 2020


Some good points by Ben & Thomas about the nature of the crash/hang. An
example to further that line of logic is x-server hanging but otherwise the
OS is still functional. Another example is I had to disable suspend on a
Linux box because every time I'd try to use it after it went into suspend,
it'd hang up.

This is where trying to ssh into it when it's hung-up might be useful in
gathering more info. You might be able to use top, ps or even tail logs.



On Thu, Jul 9, 2020 at 7:26 PM Ben Koenig <techkoenig at gmail.com> wrote:

>
> On 7/9/20 3:05 PM, Dick Steffens wrote:
> > On 7/9/20 12:13 PM, Ben Koenig wrote:
> >> Systems logs in /var/log keep a running tab of events as they occur.
> >> In the
> >> event of an unexpected shutdown the last message will be whatever was
> >> happening at the moment of the crash.
> >>
> >> You can either reboot and then scroll up in the logs to that point in
> >> time,
> >> or you can open an SSH session and monitor the log from another
> >> computer.
> >>
> >>
> >> When the crash occurs and SSH is killed you should still have the most
> >> recent message on your terminal.
> >
> > Here are the last line before the crash and the first line after
> > rebooting this morning from syslog.1.
> >
> > Jul  2 16:17:01 ThinkCentre-M58p CRON[17469]: (root) CMD (   cd / &&
> > run-parts --report /etc/cron.hourly)
> > Jul  9 10:29:37 ThinkCentre-M58p kernel: [    0.000000] microcode:
> > microcode updated early to revision 0xa0b, date = 2010-09-28
> >
> > Is there another log I should look at?
> >
>
> I can't tell you which log to look at because I don't know the nature of
> the problem. There are several logs in /var/log and any one of them
> could contain the answer. You have to put your Sherlock Holmes cap on
> and investigate the root cause of the crash.
>
>
> Since we need a lot more information the first step is to identify the
> nature of the lock up. You've said that it "hangs and needs to be
> rebooted" but what we see as a "hang" can vary depending on what
> crashed. What you want to do is go through all primary system logs in
> /var/log (dmesg, syslog, messages) and grab the last 10 or so lines
> walking backwards from the moment of the crash. A lot of that info will
> be benign but if you post it here someone may be able to help you
> identify any relevant errors being printed.
>
>
> Keep in mind that I'm not saying that these logs will tell us what is
> wrong. It's simply a troubleshooting step and if you are lucky you there
> might be an obvious cry for help sitting in dmesg that someone would
> recognize. If for some reason we can't see a problem in the standard
> system logs then there are other things that you can do to gather
> information about the crash.
>
>
>
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list