# Trying to debug system crash



## Kraust (Aug 11, 2019)

Hello,
I am trying to debug an issue where periodically my system will lock up, and this forces me to restart. There seems to be no kernel dumps in syslog, and dmesg is being wiped every reboot. Unlike in Linux, there doesn't seem to be a way for me to follow the output of dmesg, but this looks like it is being to forwarded to syslog anyways.

Where else might this be logged, I am completely stumped as to what is happening. Things just lock up at seemingly random times.


----------



## ralphbsz (Aug 11, 2019)

Shortly after boot, when syslog comes up, everything that goes to dmesg also goes to syslog. If your log is not misconfigured, it should end up in /var/log/messages. Obviously, when the system crashes, the output might stop, and in particular it might not get saved any longer.

For serious crash debugging, send the console output to a serial port, and connect a second computer there, which allows you to log everything that goes out. Takes some work to set up.


----------



## Alexander Huemeyer (Aug 11, 2019)

U could try to debug the kernel with ddb.
See: https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html


----------



## PMc (Aug 12, 2019)

Kraust said:


> Where else might this be logged, I am completely stumped as to what is happening. Things just lock up at seemingly random times.



If the system really freezes, then sadly it might not at all be logged. Because, when the system is unable to do I/O, it will also be unable to write any logfiles (which are just the same, I/O).
Definitely check /var/log/messages, You might also enable the /var/log/console.log entry in /etc/syslog.conf, which gives some more output.

Using a serial console as ralphbsz explained is the most professional approach (but I never bothered to try that out), but then, You don't explain why You don't look directly onto the console screen. There may be reasons, the system may be at a remote site, or You may be running a graphical screen - or there may be just nothing exceptional visible there.
Then, if the system is compiled with debugging support, there is a hotkey (ctrl-alt-esc) that jumps into the debugger. From there one can either try and analyze the running system, or one can try to force a kernel dump, which then could be analyzed.
Analyzing these data is not very easy, but then, one might stumble across a hint on the way. From my experience, many or most of the freezes were hardware related. So You might also check things from that side, beginning with the obvious: check system temperature, re-fasten cables, use most conservative BIOS settings, ...

Addendum: found another post where You talk about 13-CURRENT (someone of the Mods will probably soon appear and give a statement about unsupported versions), so it is imperative that You first try a RELEASE version to find out if or if not the same freezes happen there also - because without such differential knowledge it is wasted energy to investigate the matter.


----------



## Kraust (Aug 12, 2019)

I enabled console.log to see if that's going to provide me any more information on the matter, but yea I am on 13-CURRENT. If push comes to shove, I will just move to 12. Mistake on my part in installing 13 without fully understanding what 13 was.

Issue is definitely not temperature related. I've been monitoring temperature & syslog in a different monitor one of the times when the freeze occured. 

Thanks anyways, I will see if I can narrow it down further, and if not just move to 12.


----------



## SirDice (Aug 12, 2019)

As others have already noted, 13-CURRENT is a development version. Any part of it can break at any given time. Unless you do FreeBSD development you shouldn't use -CURRENT.

Also note that lockups and crashes are two different things.


----------

