“UbuntuHelp:DebuggingSystemCrash”的版本间的差异
来自Ubuntu中文
小 |
小 |
||
| 第1行： | 第1行： | ||
{{From|https://help.ubuntu.com/community/DebuggingSystemCrash}} | {{From|https://help.ubuntu.com/community/DebuggingSystemCrash}} | ||
{{Languages|UbuntuHelp:DebuggingSystemCrash}} | {{Languages|UbuntuHelp:DebuggingSystemCrash}} | ||
| − | * If your system crashes at random intervals, perform a [[UbuntuHelp:MemoryTest|MemoryTest]] '''first''' before filing any bug reports or support requests | + | * If your system crashes at random intervals, perform a [[UbuntuHelp:MemoryTest|MemoryTest]] '''first''' before filing any bug reports or support requests |
* If your system crashes when a particular action occurs, and this is repeatable every time, try the following steps: | * If your system crashes when a particular action occurs, and this is repeatable every time, try the following steps: | ||
| − | + | <ol><li>Try to reproduce the crash on a text console (`Control`+`Alt`+`F1`) if possible. If the crash occurs during startup, select the `recovery mode` option to disable the splash screen | |
| − | + | </li><li>When the crash occurs, press `Alt`+`SysRq`+`1` (one, not L) followed by `Alt`+`SysRq`+`t`. If using a text console, you should see a trace dumped to the screen. If the system is sufficiently alive, it will also be logged to `/var/log/kern.log` and visible in the output from `dmesg`. This information shows where the crash occurred, and should be included in any problem reports. If the output is not saved in any file, or the system is so bad off that you cannot retrieve it, you can either take a digital photo, or hand write the results. Almost all of the output is important (so please don't copy the one line you think is important, because context means everything).</li></ol> | |
| − | + | ||
| + | * For a full list of `Alt`+`SysRq` options, see the [http://lxr.linux.no/source/Documentation/sysrq.txt kernel documentation]. | ||
=== Remote debugging === | === Remote debugging === | ||
Some crashes, in particular those involving the X server, are impossible to reproduce on the text console. The best way is then to use a second computer from which you can log in to the "sick" machine using ssh. | Some crashes, in particular those involving the X server, are impossible to reproduce on the text console. The best way is then to use a second computer from which you can log in to the "sick" machine using ssh. | ||
| − | + | <ol><li>On the "sick" machine, install openssh-server (make sure you have good passwords on all user accounts if your machine is connected to the Internet). | |
| − | + | </li><li>On the second machine, install openssh-client. If this is a Windows machine, install Putty, a free SSH client. If it is a MacOSX machine, it already has the ssh client installed. | |
| − | + | </li><li>Find the IP address of the sick machine, for instance by running <code><nowiki>ifconfig</nowiki></code>. If both machines are running Ubuntu 7.04 or MacOSX, you can use the machine name (e.g. mycomputer.local) instead of the IP address. | |
| − | + | </li><li>Connect to the sick machine, for instance <code><nowiki>ssh [email protected]</nowiki></code> | |
| − | + | </li><li>Inside the ssh session, run <code><nowiki>sudo cat /proc/kmsg</nowiki></code> | |
| − | + | </li><li>Optionally start a second ssh session to run for instance <code><nowiki>tail -f /var/log/syslog</nowiki></code> or other commands. You can emulate the above Sys``Rq key presses, for instance the Alt+Sys``Rq+t combination, by running <code><nowiki> echo t | sudo tee /proc/sysrq-trigger</nowiki></code> | |
| − | + | </li><li>Reproduce the crash | |
| − | + | </li><li>Watch any error messages in the ssh client window on the second machine, and save them to a file that you attach to the bug report.</li></ol> | |
| + | |||
=== Comments === | === Comments === | ||
* AnthonyBarker: I would recommend entering the Bios and changing the settings to default/fail safe. After troubleshooting strange video crashes on my computer for 2 weeks it turned out it was the AGP settings in the BIOS. | * AnthonyBarker: I would recommend entering the Bios and changing the settings to default/fail safe. After troubleshooting strange video crashes on my computer for 2 weeks it turned out it was the AGP settings in the BIOS. | ||
2007年12月6日 (四) 15:14的版本
* If your system crashes at random intervals, perform a MemoryTest first before filing any bug reports or support requests
- If your system crashes when a particular action occurs, and this is repeatable every time, try the following steps:
- Try to reproduce the crash on a text console (`Control`+`Alt`+`F1`) if possible. If the crash occurs during startup, select the `recovery mode` option to disable the splash screen
- When the crash occurs, press `Alt`+`SysRq`+`1` (one, not L) followed by `Alt`+`SysRq`+`t`. If using a text console, you should see a trace dumped to the screen. If the system is sufficiently alive, it will also be logged to `/var/log/kern.log` and visible in the output from `dmesg`. This information shows where the crash occurred, and should be included in any problem reports. If the output is not saved in any file, or the system is so bad off that you cannot retrieve it, you can either take a digital photo, or hand write the results. Almost all of the output is important (so please don't copy the one line you think is important, because context means everything).
- For a full list of `Alt`+`SysRq` options, see the kernel documentation.
Remote debugging
Some crashes, in particular those involving the X server, are impossible to reproduce on the text console. The best way is then to use a second computer from which you can log in to the "sick" machine using ssh.
- On the "sick" machine, install openssh-server (make sure you have good passwords on all user accounts if your machine is connected to the Internet).
- On the second machine, install openssh-client. If this is a Windows machine, install Putty, a free SSH client. If it is a MacOSX machine, it already has the ssh client installed.
- Find the IP address of the sick machine, for instance by running
ifconfig. If both machines are running Ubuntu 7.04 or MacOSX, you can use the machine name (e.g. mycomputer.local) instead of the IP address. - Connect to the sick machine, for instance
ssh [email protected] - Inside the ssh session, run
sudo cat /proc/kmsg - Optionally start a second ssh session to run for instance
tail -f /var/log/syslogor other commands. You can emulate the above Sys``Rq key presses, for instance the Alt+Sys``Rq+t combination, by runningecho t | sudo tee /proc/sysrq-trigger - Reproduce the crash
- Watch any error messages in the ssh client window on the second machine, and save them to a file that you attach to the bug report.
Comments
- AnthonyBarker: I would recommend entering the Bios and changing the settings to default/fail safe. After troubleshooting strange video crashes on my computer for 2 weeks it turned out it was the AGP settings in the BIOS.
- Miguel: I reverted your change because I think it is wrong: you have to do this as superuser or with sudo. Please tell me in which cases the current method does not work. --Tormod
