Yakuza965

I eventually tracked this down - as you predicted - to a hardware failure. Specifically, two cores on my CPU (an Intel 14500) that were failing to respond and bringing down the whole system. I managed to capture the efi-pstore DMESG error messages, which included lines like this: <0>mce: CPUs not responding to MCE broadcast (may include false positives): 4-5 <0>mce: CPUs not responding to MCE broadcast (may include false positives): 4-5 <0>Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler <0>Shutting down cpus with NMI I manually disabled those specific cores, which made the system stable again for 5 days where it had previously silently frozen every couple of days. Then I replaced the CPU entirely. The system has been stable for 2 weeks and the old CPU is with intel for replacement under warranty. Sharing in case it helps others who have trouble with Intel CPUs down the line Thanks for the help in tracking it down.

The server hung again in the same way this morning at 0249. I managed to capture the ACPI BERT reports from the last two freezes - I saved them directly after forcing the system to reboot. I've downgraded to 7.3.0 as an experiment and will see if it continues to happen. bert-2026-06-12-0730.txt bert-dump.txt

This definitely only started with 7.3.1. I've run every version up to that upgrade and it has been stable. I'm going to see if I can capture any more detailed logs etc when it freezes next. If that yields anything helpful then great. If not I'm going to downgrade to 7.3.0 and see if it stops happening.

I did that quite a while ago but I think I’d either run out of space on the docker image a few times, or it’d got corrupted a few times, or both - and I just thought the folder might avoid that.

root@ChrisCloud:~# cat /etc/cron.d/root # Generated system monitoring schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null # Generated mover schedule: 40 3 * * * /usr/local/sbin/mover start > /dev/null 2> >(logger -t move) # Generated Unraid OS update check schedule: 11 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null # Appdata.Backup cron settings 0 03 * * * php /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php > /dev/null 2>&1 # Generated schedule for Mover Tuning move: 40 3 * * * /usr/local/emhttp/plugins/ca.mover.tuning/mover start |& logger -t move # Generated cron settings for docker autoupdates 0 3 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1 # Generated cron settings for plugin autoupdates 0 2 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1 # CRON for CA background scanning of applications 28 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

Diagnostics attached as requested. chriscloud-diagnostics-20260611-0126.zip

Since I upgraded to 7.3.1, every ~4 days, always at around 2am, my server just quietly drops off the network. I cannot access the GUI, all my dockers go offline, I cannot SSH in. The only solution is to manually power off the machine and reboot. It then stays online for about a few days before it happens again. I attach my syslog, recorded using the syslog server. As far as I can see, absolutely nothing appears to be happening before it drops offline. I've set a notification on my router for when the server drops offline, and the dates it has fired are: 10th June, 02:27 (I manually rebooted at 15:40) 6th June, 02:58 (I manually rebooted at 08:59) 2nd June, 02:19 (I manually rebooted at 18:36) 31st May, 02:16 (I manually rebooted at 07:57) I started the syslog server after that one, but it also happened before that: 29th May, 02:19 (I manually rebooted at 08:25) 28th May (I don't have a record of the time, but after this I set the notification of when it goes offline) I see a few other posts with a similar issue but there always also seems to be some other related issue. Can anyone help with diagnosing this? The system has been stable for a year or so before this issue. syslog-192.168.4.200.log