Application crashes have crash files in /var/crash/
; I'd also explore normal system logs which are your best bet. If the hardware shutdown you won't see anything in the systemd & message logs (a HUGE clue!!). If Ubuntu was aware of shutdown you'll see that too as you'll see reasons for shutdown. (If no details are found you'll need to check machine logs; ie. HOST OS if VM or hardware logs if on metal)
To look at app crashes on this box
guiverc@d960-ubu2:/de2900/ubuntu_64$ ls -la /var/crash
total 113484
drwxrwsrwt 2 root whoopsie 4096 Feb 27 12:00 .
drwxr-xr-x 16 root root 4096 Nov 29 2018 ..
-rw------- 1 root whoopsie 1214905 Feb 26 08:28 irssi-scripts.0.crash
-rw------- 1 root whoopsie 1193193 Feb 25 15:04 lvm2.0.crash
-rw-r----- 1 guiverc whoopsie 101162337 Feb 19 13:00 _usr_bin_clementine.1000.crash
-rw-r----- 1 guiverc whoopsie 5962296 Feb 26 23:31 _usr_bin_gnome-control-center.1000.crash
-rw-r----- 1 guiverc whoopsie 1519149 Feb 20 08:28 _usr_bin_light-locker.1000.crash
-rw-r----- 1 guiverc whoopsie 1327084 Feb 27 12:00 _usr_bin_totem-video-thumbnailer.1000.crash
-rw-r----- 1 guiverc whoopsie 96196 Feb 22 13:55 _usr_games_sgt-launcher.1000.crash
-rw-r----- 1 guiverc whoopsie 3685288 Feb 22 00:34 _usr_lib_ibus_ibus-ui-gtk3.1000.crash
Starting with application crashes is easy, so I'd look there first, however I can't really think of why a application crash could cause a reboot or shutdown; so I'd not expect to see anything meaningful there (if it's useful; it'll be after system logs).
To view system messages (for current session) you can use dmesg
. Because it'll show the current session only, you won't see a reason for the last shutdown (that was last session), but after an unclean shutdown I'd expect to see results of a fsck
(because of unplanned shutdown).
The best clues however are in systemd journals, or journalctl
. This is where I'd really look for clues on last shutdown, ie. it's here where I'd expect to see the lack of normal shutdown messages which means it's a clue of hardware shutdown (eg. cpu shutoff because of extreme heat threshold; a pin gets grounded with OS having no clue so messages just stop! and next message is normal booting of next session; such messages will be found in hardware logs assuming an enterprise server; consumer grade usually don't keep hardware logs).
Sometimes you can see clues of overheating in logs anyway; bad if the PSU has issues (PWR_GOOD drops) nothing will be found as CPU wasn't even aware of shutdown; I suspect hardware logs may miss this type of shutdown too (but lack of entries is still a clue!)
To further narrow down where to look though, will depend on what type of server, what is running on it, and details that haven't been provided.