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 <[email protected]> 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 > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
