kaiguy

Working great so far. Thanks @Taddeusz! Supper happy I can now use ed25519 keys.

Thanks for the heads up, @Hoopster. I've never ran into that before, but I have had an intermittent issue where trying to login to the HTML5 IPMI gui would just keep going back to the login screen. The only way to correct it was to shut down and pull the power from the server, but I might try reflashing the BMC next time I encounter it.

Closing the loop. Since disabling turbo boost (once again), I have not encountered another CPU_CATERR crash, even with some pretty intensive CPU workloads.

Thanks for sharing this. Using your script (with the minor edit that @ICDeadPpl highlighted--it was erroring out for me as well without adding the backslash). What is your recommendation, @mgutt, for identifying what is making /var/docker/overlay2 writes? I'm getting pretty consistent writes still even after incorporating the script.

For whatever reason, the QR code doesn't seem to work with my Bitwarden app. Never ran into that problem before (it just won't scan). I just tried setting up TOTP on another site and it worked just fine. Odd.

1.5.0 has dropped.

I use Adguard Home, but my unraid server specifically bypasses Adguard for DNS. My firewall does utilize blocklists, but only for ingress. So short answer is, no.

Might be too early to fully confirm, but disabling Turbo Boost has helped my server survive a few more nights without a CPU_CATERR. I'll stick with you, @Hoopster, and keep Turbo Boost disabled from now on. Thanks for your input.

Welp, started getting unraid lockups due to CPU_CATRR again after over a year of stability. No changes to my unraid or server config aside from swapping in some larger disks over the past couple of weeks. It's now happened twice in the last 4 days, the most recent one during a data rebuild. The day before the first recent CPU_CATRR I enabled Plex's new credit detection, which I believe is fairly CPU intensive. Considering the hangs have occured during the time where Plex is doing its maintenance tasks (between midnight and 4am), I'm fairly certain this is the catalyst, and makes me worry my CPU cooling is just insufficient for max load. I'm going to keep the Plex container shut down until my rebuild is complete, then I might try disabling Turbo Boost (as I seem to recall that helped back in late 2021 when I was getting it fairly frequently, but it's been enabled for quite some time now). Bummer.

Thanks, @ljm42. As I mentioned before, the unraid-api restart does show as connected for a bit, but the API_KEY under unraid-api status continues to show as invalid (after 5 seconds, 30 seconds, 10 minutes, always). Is that expected behavior? Logging out and back in does not correct the API_KEY: invalid issue.

I don’t think that’s the problem on my end, as I don’t even want to utilize unraid’s remote access. I think it’s related to the API key as showing invalid.

I recently switched firewalls from pfsense to OPNsense, so I absolutely understand that I may have mucked up some configuration. But I can't seem to track this down so I figured I might as well try to eliminate unraid/My Servers as the culprit. I setup my firewall rules pretty much exactly as before, and my topology hasn't changed. Any thoughts? When I access https://forums.unraid.net/my-servers/ , my server shows as offline. I can log out and log back in on the plugin, and it will show as online for a period of time. Not doing it this time though to show the following... This is what the My Servers section of Management Access page looks like on my server: And the API report: <-----UNRAID-API-REPORT-----> SERVER_NAME: titan ENVIRONMENT: production UNRAID_VERSION: 6.11.5 UNRAID_API_VERSION: 2.55.1 UNRAID_API_STATUS: running API_KEY: invalid MY_SERVERS: authenticated MY_SERVERS_USERNAME: kaiguy CLOUD: STATUS: [error] MINI-GRAPH: STATUS: [DISCONNECTED] ERROR: [API Disconnected] SERVERS: ONLINE: OFFLINE: ALLOWED_ORIGINS: </----UNRAID-API-REPORT-----> And output of update DNS: [email protected]:~# php /usr/local/emhttp/plugins/dynamix/include/UpdateDNS.php -v (Output is anonymized, use '-vv' to see full details) Unraid OS 6.11.5 with My Servers plugin version 2023.01.23.1223 ✅ Signed in to Unraid.net as kaiguy Use SSL is auto ✅ Rebind protection is disabled for myunraid.net Local Access url: https://192-168-0-10.hash.myunraid.net:8443 ✅ 192-168-0-10.hash.myunraid.net resolves to 192.168.0.10 Request: { "keyfile": "[redacted]", "plgversion": "2023.01.23.1223", "internalhostname": "*.hash.myunraid.net", "internalport": "8443", "internalprotocol": "https", "remoteaccess": "no", "servercomment": "unRAID 6 Server", "servername": "titan", "internalip": "192.168.0.10", "unraidreport": "{\"os\":{\"serverName\":\"titan\",\"version\":\"6.11.5\"},\"api\":{\"version\":\"2.55.1\",\"status\":\"running\",\"environment\":\"production\",\"nodeVersion\":\"v18.5.0\"},\"apiKey\":\"invalid\",\"myServers\":{\"status\":\"authenticated\",\"myServersUsername\":\"kaiguy\"},\"minigraph\":{\"status\":\"DISCONNECTED\",\"error\":\"API Disconnected\"},\"cloud\":{\"status\":\"error\"},\"flashbackup\":{\"activated\":\"yes\",\"error\":\"no\"}}" } Response (HTTP 200): [] success Attaching diagnostics. Would appreciate any feedback. Thanks! Edit: When I run unraid-api restart, the My Servers page will show as online again but the api report will still display the API_KEY as invalid. titan-diagnostics-20230209-1036.zip

For the first time the other day I noticed that Community Applications has the ability to mass update plugins/containers directly from the Apps tab. Cool new(?) feature! I'm not sure if this is expected behavior, but when I went ahead and kicked off the update from within the Apps tab, all updated non-running containers with auto-start disabled ended up being started after the update. This is not the same behavior if I would have updated from the Docker tab (non-running containers would remain non-running). Just wanted to report this observation should the desire be for the behavior to be aligned.

Appreciate sharing this fix. I was getting this with one container, then a few days later another, and finally I had 5 containers with this issue. I was pulling my hair out thinking I had some issue with my DNS blocklists.