· None of the above quite fits
· None of these quite match
· Roon Server fails to restart after update
· UniFi Dream Machine Pro Max
I am running Roon Server on a 2023 M2 Mac Mini on macOS 14.4.1. RoonServer is set up as a Login Item on my account. My account is logged in, and then the computer sits with its screen locked and acts as a home server. If I restart the computer, I log in again, and RoonServer starts as expected.
The problem starts when I run the Roon app on my iOS devices or my macOS laptop, and it says that there’s an update available. When I click the “update all” button, my app updates, and the server on the Mini also updates, as expected. However, the server does not restart post-update. So the app on my phone/Mac re-launches after the update and then says it can’t contact the server.
I then have to go to my server and unlock the screen (or remote in with Screen Sharing), go find the RoonServer application (/Applications/Roon.app/Contents/RoonServer.app) and launch it manually.
Is there some configuration that needs to be changed for this to work properly? Given how frequently Roon is updated, this is quite a chore.
To track this down properly, we need to match your report against the exact moment it happens. Could you please help with a few things the next time Roon Server doesn’t come back on its own after an update:
Thanks. I’ll have to wait until the next Roon update, I guess, in order to give you exact timing.
I can answer #2 and 3 now, though:
2: The only Roon-related item in Login Items is RoonServer.
3: Every single update.
Hey @Michael_Kobb,
Thanks for the extra detail, the Login Items info and “every single update” answer are exactly what we needed, and I’ve now been through the server logs on our end. Here’s what’s going on.
The update itself is working perfectly. On your last update (2.67 → 2.70, build 1671), the installer ran cleanly and staged the new version with no errors, then marked it “Pending”, meaning it’s downloaded and ready, and just needs Roon Server to quit and relaunch to apply it. There are no crashes or corruption anywhere in the logs; the engine is healthy.
The snag is that relaunch step. Applying a staged update requires Roon Server to close and be re-opened by macOS, and that re-open needs an active, unlocked login session to launch into. Because your Mini runs as a headless server, logged in but sitting at a locked screen, started from the RoonServer Login Item, there’s no active GUI session for macOS to relaunch the app into, so it stays down until you unlock and open it manually. That lines up exactly with what you’re seeing: install succeeds, server never comes back, manual launch fixes it, every time.
A couple of things that would help:
To confirm the diagnosis, the next time it happens, could you open
on the Mini, filter for “RoonServer,” and note any messages around the update time? That’ll show us the relaunch attempt directly.
Let me know which direction you’d like to go and I’ll get you the exact steps. Thank you! 
Yep, that makes complete sense. Is this a macOS limitation on launching the new version? For software called a “server”, surely it’s not unexpected that the machine is running headless with the screen locked.
Next time it happens I will check the logs just to confirm, but in the meantime, what I’d really like is a way to not have to log into my server every time Roon updates.
Hey @Michael_Kobb,
That’s a completely fair point, and I actually mispoke in my prior reply. Roon Server’s updater is actually designed to relaunch itself after applying an update, without anyone logging in or unlocking the screen, so “it’s a server, it shouldn’t need a GUI session” is exactly right, and my earlier explanation doesn’t hold up against your logs.
Digging into the same server logs, the 2.67 → 2.70 update staged perfectly. The installer copied the new build in, marked it Pending, the old version exited cleanly, and the new build came up about 30 seconds later with no crashes or corruption anywhere, and it’s run continuously since. So the mechanism that’s supposed to bring it back headless clearly can work on your machine. That’s why I don’t think a locked screen is the real culprit, and something more specific is getting in the way on the updates where it fails for you.
The Console capture you offered is the key piece here. Next time it happens, on the Mini open Console, filter for both RoonServer and RoonAppliance, and grab everything around the update time, that’ll tell us whether the launcher is even attempting the relaunch and hitting an error, versus never firing at all.
Two quick things that would help in the meantime:
There are a bunch of different options in the Console app. Which view should I be in when I try filtering by RoonServer and RoonAppliance?
Hey @Michael_Kobb,
Good call, here’s how to set it up:
RoonServer and hit return, then click the filter chip it creates and set it to Process. You can add a second term for RoonAppliance the same way, joined as "Any," so you catch both.
log show --predicate 'process == "RoonServer" OR process == "RoonAppliance"' --info --debug --last 30mAdjust –last 30m to cover the window since the update. That’ll capture everything regardless of whether Console was open at the time, and you can paste the output here.
Whichever’s easier for you works. Thank you!
Hey @Michael_Kobb,
Just checking in on this. Were you able to open the Mac mini’s live log stream in Console, turn on both Info and Debug messages, and filter for RoonServer and RoonAppliance the way we outlined? If the issue already happened and you were not able to catch it live, the Terminal command we sent should still pull the last 30 minutes of history after the failure, so either path works, and we can take a look at whichever output is easiest to grab. Please reply with any updates or paste the log output here if you have it.
Please note, if we don’t hear back from you this thread may close automatically soon. If the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.