Every few weeks MATE Noble 24.04.2 crashes and/or logs me out which closes all applications. This didn't used to happen on Intel CPU but does regularly on AMD CPU.
When it logged me out earlier today I was running VirtualBox 7.1.6 and Audacity 3.7.1
Where should I look to provide more information?
Firstly I'd look for crash files, ie. look in /var/crash/ and just use the files metadata (ie. datestamps) to find any that match timewise.
Next I'd explore system logs, dmesg can be useful IF you've not rebooted; though systemd journals (journalctl) survive reboot; besides timestamps are easier to read in the systemd journal too, but scan both.
If the apps are 3rd party, you may get less (or no) details reported in /var/crash, but I'd still start looking there.
Was
or
Also, if the first, was the VirtualBox hosting Windows/Mac and doing something ?
I offer this if you haven't done the lookup yet:
Also, don't know if you need to review this discussion:
And this one seems share your specific observations, and the feedback seems to suggest the problem is related to NFS, with the recommendation being to switch to iSCSI:
I had a similar issue. I could not find anything in the syslogs. But I think I identified the issue, my cpu. I added a sensor monitor to the task bar. The CPU temp bounces all over. Bouncing between 17 and 50 frequently. I think the sensor itself must be going bad. I suspect the PC shut down for an overheated cpu. You could try adding the COU Frequency Monitor to your task bar and setting the CPU to poswersave or conservative and see if problem continues.
Thank you for mentioning that, Jay!
I myself do experience system "panic" when the CPU overheats. When the CPU reaches an internal "safe" threshold (not specified by me), it simply triggers a Motherboard power-down, no system "shutdown" action. The next boot forces an fsck on all partitions. 
That happens when the CPU is under intense load. So, I implemented a mechanism to control and hold the CPU frequency at 75% of max(discussion here and custom script here), but even then, Core Temperature creeps up into the "danger" zone (over 80 C for me) if it is doing something like a video format conversion using HandBrake. Thankfully, HandBrake has a "Pause" function that I use when the temperature creeps up too high, in order to allow that Core temp to drop back to a safer value.
Thanks to all for the replies.
Just now, UbuntuMATE 24.04.2 host crashed all the way to the black screen.
@guiverc
The most recent file in /var/crash is a few days old. So not related to today's crash.
I don't really understand how to use journalctl
@ericmarceau
UbuntuMATE 24.04.2 is hosting VirtualBox 7.1.10.169112 (I just recently upgraded VirtualBox from virtualbox.org)
and
VirtualBox was hosting a few UbuntuMATE VMs
I wasn't running any Windows or Mac VMs
I'll go through the list you posted in more detail next.
@jaybo
I added the HardwareSensorsMonitor to the taskbar. The temps are pretty stable.
Update on temperatures: Tccd1 moves around between 49°C and 57°C within seconds.
This is on an AMD Ryzen 7 5800XT
So, unless your CPU has a much lower "panic" setting, it appears that the issue is not CPU core overheat.
I have a new file in /var/crash . Here's an extract from it. Does any of this look relevant?
root<at>H2a:/var/crash# ls -l
total 2952
-rw-r----- 1 root whoopsie 3022254 Jun 9 18:12 _usr_sbin_smbd.0.crash
root<at>H2a:/var/crash# grep "^[^ ]" _usr_sbin_smbd.0.crash
ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Mon Jun 9 18:12:19 2025
Dependencies:
DistroRelease: Ubuntu 24.04
ExecutablePath: /usr/sbin/smbd
ExecutableTimestamp: 1712587765
Package: samba 2:4.19.5+dfsg-4ubuntu9
PackageArchitecture: amd64
ProcCmdline: smbd:\ client\ [192.168.11.115]
ProcCwd: /z/f
ProcEnviron:
ProcMaps:
ProcStatus:
Signal: 6
SignalName: SIGABRT
SourcePackage: samba
Uname: Linux 6.8.0-60-generic x86_64
UserGroups: N/A
_HooksRun: no
CoreDump: base64
root<at>H2a:/var/crash#
I'm not going to know, and a single crash report maybe related to something else.
That file relates to a SaMBa issue and is networking related... I don't routinely use SMB/SaMBa/CIFS as I use & prefer NFS, and I have no clues as to what devices, and how you use SMB.
The timestamp detail of when crashes occur is where I tend to look for patterns. What time/dates do crashes occur? same time each week? something happen at that time; eg. I have disk storage devices here that perform self checks once per month at a specific time, and thus those devices networking capabilities are reduced for a number of hours during those self-checks; the devices I'm thinking do provide SMB services. SMB points to networking; so is it related to networking?
Another network related issue I've experienced was a powerpack on a cheap networking-switch was going bad; and that would cause switch to misbehave & drop traffic.. took me some time to detect that; as that showed itself via some apps hanging as they'd not get responses due to lost traffic.
The more detail you gather, the better you can detect patterns & thus come up with an action plan for finding the cause. The effect of a network/SaMBA crash only you can likely interpret as it need knowledge of your network.
I think this advice has been overlooked.
Use journalctl -b -1 to view the log from the previous boot (the one that crashed) if the system resets. It's not guaranteed to contain all the information (even for a soft reset) but there might be some logged errors leading up to the crash 
As your posted text, and Chris's comments indicate, the SAMBA is a networking issue. For that reason, I encourage you, once again, to review the link I previously posted regarding this issue, to be sure that whether it does, or does not, apply in your case.
Making note about such a determination, here for everyone to see, would help document for any other possible Community members what is a workable solution ... or not.
@ericmarceau
Thanks for the reply. I had another look at the images (not a link) you posted. Unfortunately those ideas are for when a single guest VM exits.
My issue is that either
(1) the host Ubuntu MATE logs out the currently logged in user, which exits all applications including all guest VMs or
(2) the entire host Ubuntu MATE reboots all the way to the black screen where I could enter the BIOS.
If you have any ideas for my use case, please do let me know.
Thanks!!
There is a very good introduction to journalctl at
Entering journalctl presents you with a scrolling view of the logs, but the key-command interaction is like when you are in vi/vim/gvim: "/" for search, "gg" takes you to the top/HOME, "G" takes you to the end of the log, etc.
BTW, if your install has the systemd service journal logging set to persistent, they will all be found under the directory
/var/log/journal/*
In my case, it appears that these are being kept for up to 8 weeks, after which they are purged.