I noticed my music server, Salkstream III running Archlinux/Roonserver, rebooted randomly twice in the past week. Fortunately, it didn’t happen while listening to music, though I haven’t used Roon much this past week. I leave the Salkstream powered on all the time unless I need to shut down or reboot for a particular reason.
I posted in the Archlinux forum, and so far the feedback is there isn’t anything in my OS system logs to indicate why it rebooted.
Could Roon be doing something in the background that would cause the OS to reboot that doesn’t show up in the OS logs?
I don’t know what to make of this. It is only by chance I even noticed the reboots. I just happened to be sitting by one of my Roon endpoints (Logitech Touch), and noticed it temporarily lose connection with Roon. Upon investigation, I discovered the Archlinux OS had rebooted. Since then I’ve been checking the “uptime” on the Salkstream, which is where I saw it rebooted again today.
So far, it hasn’t happened while listening to music, but I often go days without using it, so I don’t know how long this may have been happening.
The Salkstream itself seems fine; CPU temp is fine, it’s clean inside (I was surprised how little dust was in it, though being fanless surely helps), and I reseated the RAM modules to assure good contact. Google said it could also be a failing power supply, but it never loses power unexpectedly (any power interruption will cause it to shut off and it is not set up to turn back on automatically).
I have the same on my Asus Nuc 13 with Roon Rock installed directly. It randomly reboots. The longest period between the reboot is about 5 days. Yesterday I increased the memoy from 8Gb memory to 16GB (2 × 8). There is no noticable case for this behavior so far.
Okay I don’t know wether a software can reforce a reboot of a operatng system. Was just my bet.
what I do know is that Roon can crash on low budget memory. That said one might wonder how an app can run out of 8GB on a local library with 81000 tracks and even doing so when I don’t use Roon at all.
Well, not with a regular general-purpose OS where there’s a clear separation of user processes and the OS. And that’s what @Saturn94 uses more or less (though the inner workings of Salkstream are a bit of a mystery even though it is based on Arch Linux).
However, as I said, it’s a bit different for you with ROCK, because ROCK uses Roon OS, which is not a general-purpose OS, and it’s well known that Roon OS crashes (as designed on purpose) if it runs out of RAM. So it’s possible that this is what happened to you.
It probably shouldn’t, as the Nucleus One comes with only 4GB and is rated for 100,000 tracks. However, it might depend on library specifics or there might be a bug. You could open a Support case and have them take a look at your logs.
Anyway, my point was that there are considerable differences between Roon OS and Salkstream or other more general OSes.
So far, there is still no explanation for the “ghost” reboots. According to those who have responded to my post in the Archlinux forum, nothing in the logs show any problems that explain this. It was mentioned, “…That’s a controlled and deliberate reboot and apparently it required polkit for privilege authentication…doesn’t seem to come from an interactive session, there doesn’t seem to be a cron daemon and the logged systemd timers look unsuspicious.” It was also mentioned that if Roon triggered the reboot, it should show in the logs.
Another poster mentioned, “…the fact that it’s a clean reboot with no user ID (UID) really points toward a low-level trigger, like a minor power fluctuation or a firmware safety reset….Run the new kernel (6.18.9) and watch it for a week. Most of these ‘ghost’ reboots are fixed by the stability improvements in newer kernels I guess…”.
So I guess at this point, I’ll just monitor it for any more ghost reboots. Here’s hoping the updating the OS again last night to 6.18.9 arch1-2 (I last updated Feb 6th to 6.18.7 arch1-1 after I noticed the first ghost reboot) will fix this.
A user on the Archlinux forum helped me set up logging for “polkit”. As I understand it, should a “ghost reboot” occur again, this might help determine what triggered the reboot.
As best I can tell, hardware is ok. I was told in the Archlinux forum there are no signs of memory, drive, or other hardware issues in the logs. Running “sensors”, I can see the CPU temp is normal.
I haven’t opened the Salkstream since 2020 (internal HDD was replaced in Nov 2020), so I opened it to see if it needed cleaning. I was pleasantly surprised to see there was very little dust inside (fanless case). It still looks brand new inside. I cleaned out what little dust there was and reseated the two RAM sticks to assure they have good a connection.
It was mentioned that a small power fluctuation might be enough trigger the OS to reboot without the Salkstream actually shutting down. Maybe the power brick is showing its age (I bought the Salkstream June 2016)?
I was told the logs show the reboots were intentional, but didn’t show what “requested” the reboots. Supposedly, activating polkit logging should show what is requesting the reboots should it happen again. So for now, I’m waiting to see if it happens again and see what the polkit log says.
Another reboot occurred today. If I’m understanding correctly from feedback on the Archlinux forum, the logs now show another user called “http” requested the reboot. The feedback I’m getting from the logs and information I’ve provided indicates there is nothing malicious going on (thank goodness!).
So, the question is, why is there an “http” user set up to allow full access, and why is it requesting reboots?
I wonder if this has something to do with a feature of the Salkstream that allows the owner to access the streamer via a web browser (essentially a Salkstream “webpage” to check system info, perform safe reboots or shutdowns, read about the Salkstream, etc)? Or could it be something Roonserver requires to keep in contact with Roon’s servers? Either way, I don’t know why either would request an OS reboot.
I’ve been told it could be a customization the manufacturer added to the Salkstream’s Archlinux OS. Unfortunately, if this is the case, the members of the Archlinux forum won’t be able to help further since they don’t know what customizations/modifications may have been made. They suggested contacting Salk.
Up until now, I’ve been reluctant to contact Jim Salk since he closed the business and retired in 2023. He did say back then he would continue to support his customers, but I feel bad bugging him all this time later. Since I don’t seem to have other options for answers, I went ahead and sent him an email. Hopefully, he can provide some clarity on what’s happening.
If I don’t find out what’s happening, I may just forget about it since it doesn’t seem to be affecting my use of Roon. If it starts to affect my use of Roon in the future, I’ll revisit it then, perhaps even ditch Archlinux and go with something better supported here such as DietPi (that would be an entirely new adventure…eek!).
You don’t need any German, that was just the first link I found.
The idea is
install some linux (my all time favourite is debian) onto a usb disk
plug this disk into your device and boot it up
perform a hardware check, e.g. with the stress utility mentioned (I have never used it). Check memory (memtest86) and the file systems (fsck).
install roon server and check if it is stable with this system. So you don’t have to wipe your software just to check if it has an error. Your library might also cause errors, so first try roon without connecting your downloads.
I heard back from Mr. Salk. Unfortunately, he couldn’t explain what is happening. He said he could probably figure it out if he had my Salkstream there, but it would be easier and faster just to replace my OS/Roonserver, presumably to wipe out any OS issues my unit may have. Frankly, I’m amazed that Mr. Salk still offers to help customers years after retiring, and on a 10 year old streamer!
Given that the reboots in question have never occurred while I’m using the Salkstream, and according to the Archlinux forum my logs indicate these reboots are intentional and not due to malicious activity, I’m inclined to not go through the trouble of shipping my Salkstream back to Salk and just enjoy it until it actually exhibits behavior that interferes with my use of it.
Should it come to that, I’ll need to learn how to do as you suggested (I know next to nothing about Linux 
).