Linux logs system crash

Get more information about the crash

When I issue the command last in my terminal I see the following entries i.e. «crash»: i meant the command last » show listing of last logged in users».

root@lab18:~# last tito pts/3 x.x.x.x Tue Nov 13 16:22 still logged in tito pts/3 x.x.x.x Tue Nov 13 09:13 - 16:22 (07:09) reboot system boot 3.2.0-32-generic Mon Nov 12 23:58 - 16:22 (16:24) tito pts/1 192.168.26.5 Mon Nov 12 23:56 - crash (00:01) tito pts/4 192.168.26.5 Mon Nov 12 22:46 - crash (01:12) uname -a Linux HomeServer 3.2.0-32-generic-pae #51-Ubuntu SMP Wed Sep 26 21:54:23 UTC 2012 i686 i686 i386 GNU/Linux last reboot reboot system boot 3.2.0-32-generic Mon Nov 12 23:58 - 16:29 (16:31) wtmp begins Thu Nov 1 10:17:16 2012 

I have found some information about the crash in the syslog and the kernel.log However i was curious if various linux distributions (ubuntu) is writing some other files other than the syslog or kernel.log where specific information about the crash can be decoded. And what I mean is for example many networking vendors do i.e. cisco, hp, juniper, enterasys do have syslog, current.log files, SNMP informs/traps messages, that are saved to some sort of place locally on the file system or remotely in case an even occur, however they also have specifically designed files such as systemDumps where a backtrace from the callstack can be found and analyzed in case a crash occur and occasionally this could help to debug the problem. So the question is does Ubuntu has also such kind of place where information is being stored about the crash. Regards, Tito

Источник

Debugging techniques

If a kernel crash completely locks the system, take a look at https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe.

log files

If using linux-crashdump (above) is not successful try and see if any backtrace was logged to one of the kern.log files according to their time stamp (ex. /var/log/kern.log). Please attach this file if anything was captured.

SSH

1. 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).
2. 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.
3. Find the IP address of the sick machine, for instance by running ip addr. 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.
4. Connect to the sick machine, for instance ssh myuser@192.168.1.3
5. Inside the ssh session, run sudo cat /proc/kmsg
6. Optionally start a second ssh session to run for instance tail -f /var/log/syslog or other commands. You can emulate the above Sys Rq key presses, for instance the Alt+Sys Rq+t combination, by running echo t | sudo tee /proc/sysrq-trigger
7. Reproduce the crash
8. 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.

Netconsole

If the above doesn’t work, one may use Netconsole.

In X window mode

Sometimes crashes occur in X, and so terminal access is not available (to capture the kernel backtrace). When this occurs, the user should try to recreate the crash at the console (Ctrl+Alt+F1). If this is not possible, then annotate the bug as such.

Other crashes

If the X server crashes (you’re thrown back to the login screen, or screen goes black or frozen but there is activity «below») see DebuggingXorg. See DebuggingProgramCrash if just a program and not the whole system is crashing.

DebuggingSystemCrash (последним исправлял пользователь 28 2015-06-23 11:54:47)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

When an application crash without output an error, is there a log that i can check?

Sometimes it happen that some application crash without give no output error (conky in my case, probably is one of my configuration that is incorrect). Is there somewhere a error log that I can check to understand why it is crashed?

6 Answers 6

Depends on the application. Different applications have different logging systems; there’s no one central log that contains all the output from all the programs that run on your system.

That being said, a lot of programs do put their log files in the directory /var/log . The file /var/log/syslog (or maybe /var/log/messages ), in particular, contains output from the «system logger», which is a service made available by the system that programs can use (if they choose to) for logging. But not all programs use it. Mostly, you’ll find messages from low-level system services in that file, not the graphical applications you probably use normally.

crash files go into /var/log/crashes/ for use with apport to report bugs. You can extract a core dump with apport-unpack , put that core dump through gdb, and find out what’s causing the program to crash.

This is all assuming you’re a programmer. If you’re not. well, you can’t fix the crash anyway!

«This is all assuming you’re a programmer. If you’re not. well, you can’t fix the crash anyway!» with open-source we all can try to solve our problems, at our own risk obviously 😉

@DaNiel: Not really! If you are not a programmer and you don’t have a good understanding of the applications code, the more you mess with the code the buggier with will probably get 🙂

Even if you’re not a programmer sometimes looking a core dump can give you idea about the problem. For example, it seems like it’s crashing in some kind of graphics routine—maybe I should updated my display driver.

Do you know non-programmers who can use gdb? I’m a programmer and can get as far as bt full «oh look a backtrace. with missing symbols. guess I need to install debug symbols and try to reproduce the crash. » I once figured out how to set a breakpoint. that’s the most advanced I’ve gotten with it though.

For conky it could also be that there are entries in $HOME/.xsession-errors .

Some applications have flags that can be used to turn on debugging, such as -d, -D, —debug, etc. Check the application’s man page ( man [my-app] ) or run the app with the -h flag to see if it has such an option.

Many GUI apps write into $HOME/.xsession-errors so that’s a good place to check for output.

maco’s right that apport is probably the most sure-fire way to get good debug info. Sometimes it doesn’t capture the crash, though.

If all else fails, you can also force the info out of it by running the app in gdb. It’d be something like:

. do whatever is needed to get it to crash .

Источник

How can we trace problems of crashing programs in Linux?

If an application crashes in Windows we can check the Event Viewer in the Administration tools to see what has crashed. Sometimes it has useful information others not, but it is a start.
In linux if an application (any) crashes how one starts to trace what happened?
Is there e.g. some central log or something similar?

The standard way of debugging this kind of thing is to launch the problematic application from a terminal manually. That way you can see any error messages printed.

64-bit versions of Linux will log a short description of a crashed process (one that died due to a signal) in /var/log/syslog . Linux provides a way for a daemon to be notified of process crashes. Ubuntu’s apport and Red Hat’s abrt use this to provide centralized logging and report-generation facilities. Generally a core dump is saved so that you can invoke a debugger on the crashed program.

I would have upvoted this question, but the OP does not seem to want to help the community by accepting, or posting, an answer, so I will find a similar question which does accept an answer and upvote that, in the hope that it will rise to the top of search results and help future searchers

4 Answers 4

Is there e.g. some central log or something similar?

The normal place for system logs is /var/log/ . What gets put in each log depends on the syslog configuration, but commonly everything except logins goes to /var/log/syslog .

This is no guarantee that individual applications will have left any clue there in the event of a problem. But they, or the shell, will likely spit something to the standard out/standard error streams, and if you run a troublesome application in the foreground from a terminal you’ll be able to see that stuff.

If you can make the crash happen, do so, then see which file under /var/log was most recently changed. With ls -lart , the last file in the listing was the most recently changed.

There are conventions — linux is much more heterogeneous than windows. Syslog refers to the system logger, but there is not a universal implementation, and the variations can then be configured in different ways. The general logic is that messages are sent to syslog by the application, and these messages are then sorted into different files. As mentioned, commonly everything ends up in /var/log/syslog , but different distros do things differently. If you know what which syslog you are using, you can examine its configuration to determine this.

Источник

How to check Ubuntu crash log in last session?

My headless Ubuntu (11.10) crashed. When I plug in keyboard and monitor, I see an non-interactive cursor (no blink) on a black screen. SSh, telnet don’t work from other machines. Ping works. I have restarted the machine. How could I check the log files of the last session, so I can know more about this crash?

They are for this session right? I already restarted the box. What are the file name patterns for the last session’s logs?

The ones that ends in .1 are from the last syslog session. A quick ls -lta /var/log will give you an idea of which files are new.

I discovered those files: alternatives.log.1 daemon.log.1 dpkg.log.1 kern.log.1 messages.1 syslog.1 auth.log.1 debug.1 jockey.log.1 lpr.log.1 pm-powersave.log.1 user.log.1 . messages.1 is the biggest file. So I assume it is the file that most likely has the information I need.

1 Answer 1

On Ubuntu (running 13.10 as of this day), the /var/log/apport.log contains crash log messages, which is rotated per configuration in /etc/logrotate.d/apport. The actual crash reports are saved in /var/crash/ — Not sure how relevant this information is with regard to other releases. Also, this may only be true with apport enabled (https://wiki.ubuntu.com/Apport#How_to_enable_apport).

You must log in to answer this question.

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник