38

Yesterday, I ran a bash script for about 10 hours. When I went to use the computer, it locked up.

  • I have an Eee PC with Debian.
  • The screen was still visible, but the mouse or keyboard had not effect.
  • I tried CtrlAltDelete, CtrlAltBackspace, CtrlAltF1, but to no effect.
  • The hard drive light showed no activity.

How can I determine what went wrong? What logs can I check?

jasonwryan
  • 71,734
  • 34
  • 193
  • 226
Village
  • 4,655
  • 14
  • 46
  • 80

4 Answers4

22

You can find all messages in /var/log/syslog and in other /var/log/ files. Old messages are in /var/log/syslog.1, /var/log/syslog.2.gz etc. if logrotate is installed.

However, if the kernel really locks up, the probability is low that you will find any related message.

It could be, that only the X server locks up. In this case, you can usually still access the PC over network via ssh (if you have installed it). There is also the Magic SysRq key to unRaw the keyboard such that the shortcuts you tried could work, too.

jofel
  • 26,513
  • 6
  • 65
  • 92
9

you can read /var/log/dmesg for any software problems like [ kernel ] , if it was a service error you may read the service's log like apache for example /var/log/apache/error.log

I guess some hardware errors can't have log

tawfekov
  • 191
  • 4
3

I can't give you with exact commands that can help you get data. But general approach to find the culprit is to some how capture output of commands at regular interval. This will help as you will have data from commands executed before system crashed.

You can capture output of these commands by scheduling them using crontab (HowTo: Add Jobs To cron Under Linux or UNIX?).

Alternatively, there is a service SeaLion - Linux server monitoring and debugging tool where you can schedule commands and check your system's status online.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
jsist
  • 131
  • 2
1

I stumbled across this post while Googling the log issue but for others' reference concerning the failure of the OP's machine to respond to the reboot, X server kill, and tty commands entered from the keyboard I would add this:

While hardware power options (e.g., the reset and power buttons, or simply unplugging the machine) are always available, I have found that in these cases, a machine often responds to SysRq commands, including Alt+SysRq+b (i.e., reboot).

SysRq must be enabled, however. In Ubuntu 20.04, this means either doing:

echo 1 > /proc/sys/kernel/sysrq

for the current session or, for persistent configuration, having the following appear in /etc/sysctl.conf:

kernel.sysrq=1

This procedure may differ for other distributions.

I would hasten to add a recommendation to review other available SysRq commands before invoking Alt+SysRq+b because it will immediately reboot a system before putting it into a stable state, which may create other difficulties including file corruption. These other commands and command sequences are well documented elsewhere.

ebsf
  • 271
  • 2
  • 11