I’m hoping someone can give me a direction here because I’m basically out of ideas.
So I have a new Odroid XU4 that’s running the latest DietPi off of a 32GB Emmc. I am using the 6A Odroid power brick to ensure this isn’t a power drop issue. I do have a 120GB SSD (Samsung EVO) attached via the USB 3 port (so low power device shouldn’t be causing a problem that I’m aware of.) I’ve changed the default blue heat sink for a much larger north bridge one and am using Arctic Grizzly as the grease so after stress testing this setup it never got over 63 Celsius. The only software running on it is the base system with the following software:
Sonarr
Jacket
NZBGet
CouchPotato
Deluge
Samba (just to connect to a single share on a different box to send completed files)
I have it setup for automatic running but haven’t modified any internal scripts or anything of that nature. I’ve only ever changed the settings for the various apps themselves. It’s connecting to the web via the Eth0 using DHCP.
What happens is that it’ll run seemingly fine for anywhere from 5 minutes to a little over a day eventually leading to the Odroid freezing. No warnings and no failures (that I can see). There doesn’t seem to be any particular combination of running apps that causes the freeze and it always requires me to pull the power and restart to get it back up and running. This has been the same since I first got the droid itself and had everything as defaults (4A power supply, stock cooler, no USB drive). I’m not sure what could be causing all of this unless maybe it’s getting a panic somewhere along the way and simply not showing it or logging it (if it is, I’m not sure where to look). So my question would be is has anyone else had this problem? If so, could you share what you did to remedy it? Is there something else I should be looking at to solve the issue?
Any help would be much appreciated. Thanks guys!
To eliminate the eMMC as the source of the problem try cloning the os to an SD card and see if that works. Odroid claim very low failure rate for eMMC but I’ve had two fail and they offer a very short warranty period (one or three months if I remember correctly).
John
Ok, I can do that. Is there a way to find out via log(s) that might indicate that this is the issue?
Hmm to check the log before failure (after reboot) you need to disable dietpi-ramlog. Easiest would be to completely disable/uninstall every logging system within dietpi-software to enable systemd-journald logging everything. Then you need it to do persistent logging:
mkdir /var/log/journal
Then run “journalctl” after failure and check for logs before the freeze.
It might also help to do a file system check on reboot:
> /forcefsck
reboot
Ok, so I’ve done what’s been suggested so far and I’m still getting the same results. I’m still not able to get a log that might indicate what’s going on. Just off the top of everyone’s heads, what could conceivably be the reason(s) for the lock ups?
percivul
Do you have access to the logs now after reboot, via journalctl? Maybe you could post the last few entries before the freeze, even there are no errors, the running/started tasks etc. could still give a hint.
Generally of course there are many possible reasons for freezes. Most commonly indeed is insufficient power supply. There not only the max current is important, but also the stability of the provided voltage. This is basically the quality measure of a power supply: How quick the voltage is adjusted to precisely 5V, after large actual current changes, in case even the quality of the sinus signal, how well it is encapsulated etc.
- To check such, e.g. the start of a heavy cron job or systemd unit (via timer) could be an indicator. In case just the timestamp of the last log entry before freeze (boot messages), to check if it closely matches the usual cron job hourly time e.g.
Ah did you check if underclocking the device helps?
Besides power, I guess corrupted SD cards are then mostly a reason for failures or even freezes. Not sure about quality of Odroids eMMC, especially since it’s new, but all MMC have a very limited lifetime (compared to SSDs, HDDs etc.), I guess.
You could do some bad block test on the eMMC, if really no other reason was found. In case it should be possible to replace the Odroid via guarantee. But yeah follow johnvick on try it via SD card is easier and has less impact on eMMC lifetime 
.
Odroid’s eMMC warranty period is so short it is worthless. After two failed, I’ll stick to SD. With a good Sandisk extreme I don’t notice much difference.
John
Ok, so still no logs BUT I did notice something interesting. Sonarr seems to be throwing failures intermittently. I am using the developer branch but have gotten the same results with the master branch (release branch). I’ve tried manually shutting down the thread as well as using dietpi-services and in both cases, the program seems to want to “stick” which forces me to either kill the thread directly (which pisses mono off to no end) or reboot the whole system. So, kind of a new question but is there a way to logs for what Sonarr is doing? The NZBGet forums aren’t very helpful in this endeavor so I’m hoping someone here will know about this or can at least point me in the right direction.