I have a server that was doing a data rebuild (94% on Friday) and at some point Friday night my server became unresponsive. Couple questions:

1. Is it safe for me to reboot without knowing the status of the rebuild?

2. Is there a way for me to see the status of the rebuild on the console?

3. How do I get diagnostics saved from console on the usb stick so I can reboot and grab the zip to see why the heck my server keeps becoming unresponsive after 24-72hrs.

I am running 7.3.1, however I tried 7.2.x and 7.3.0 with same issues. I thought my issue was the drive I had failing so I put in a backup drive. Unfortunately that doesn’t seem to be it either.

5 hours ago, wickedathletes said:

How do I get diagnostics saved from console

Click the link

If that fails, see if you can get the syslog

cp /var/log/syslog /boot/syslog.txt

6 hours ago, JorgeB said:

Click the link

If that fails, see if you can get the syslog

cp /var/log/syslog /boot/syslog.txt

thank you. is it safe to reboot whether the parity rebuild finished or not, if you know.

See if you can avoid a reboot until after you've collected the diagnostics if you are able too, otherwise the relevant information is lost.

5 minutes ago, MowMdown said:

See if you can avoid a reboot until after you've collected the diagnostics if you are able too, otherwise the relevant information is lost.

yes, I was able to grab the diagnostics, I am more wondering if the reboot is safe if the data rebuild was still happening. That said, it looks like it had finished so I rebooted.

2 minutes ago, wickedathletes said:

I was able to grab the diagnostics,

Post them and setup syslog server.

hades-diagnostics-20260608-0953.ziplogs attached. Seeing a ton of this:

Jun 5 17:04:24 HADES php-fpm[11183]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Jun 5 17:08:25 HADES nginx: 2026/06/05 17:08:25 [error] 11342#11342: *153975 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.0.0.74, server: 10-0-0-218.90e2fe0d49f96ca5d5fa9dc615c0641bedcef03e.myunraid.net, request: "POST /webGui/include/Report.php HTTP/2.0", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "10-0-0-218.90e2fe0d49f96ca5d5fa9dc615c0641bedcef03e.myunraid.net:446", referrer:

Rebuild finished a couple of days ago:

Jun 5 16:42:30 HADES kernel: md: sync done. time=14045sec

Jun 5 16:42:30 HADES kernel: md: recovery thread: exit status: 0

52 minutes ago, JorgeB said:

Rebuild finished a couple of days ago:

Jun 5 16:42:30 HADES kernel: md: sync done. time=14045sec

Jun 5 16:42:30 HADES kernel: md: recovery thread: exit status: 0

thank you, I noticed that via a command line i found to use so I rebooted. Now just trying to figure out why I keep crashing.

You can enable the syslog server and post that if it crashes again.

13 minutes ago, JorgeB said:

You can enable the syslog server and post that if it crashes again.

do the attached logs not show the reason for crash? its been crashing for a few weeks now, I was able to capture "diagnostics" before rebooting, its attached.

Don't see anything that would justify a crash, and since you were still able to get the diags, the server was not really crashed, I do see a lot of these:

Jun 5 17:10:17 HADES nginx: 2026/06/05 17:10:17 [error] 11342#11342: *153975 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.0.0.74, server: hash.myunraid.net, request: "GET /plugins/dwmemtester/include/dwmemtester_status.php?getfs=no HTTP/2.0", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "hash.myunraid.net:446", referrer:

Suggesting an issue with that plugin, possibly could make the GUI stop responding; you can try booting in safe mode.

syslog.ziphades-diagnostics-20260611-1008.zip

attached are the latest round of logs. I removed 2 plugins as well. Hopefully this helps in some way to diagnose what could be causing this issue? Like clockwork, the server becomes unresponsive after 48-72hrs.

Still seeing some Nginx errors that could be caused by a plugin, my recommendation is the same

On 6/8/2026 at 6:41 PM, JorgeB said:

you can try booting in safe mode.

4 minutes ago, JorgeB said:

Still seeing some Nginx errors that could be caused by a plugin, my recommendation is the same

boot into safe mode and see if it, it eventually fails again in 2-3 days? Just trying to figure out what this is checking? Is it because plugins and dockers aren't turned on doing that?

1 hour ago, wickedathletes said:

boot into safe mode and see if it, it eventually fails again in 2-3 days?

Correct, to rule out a plugin issue.

hades-diagnostics-20260614-1903.zip

I plan to start safe mode soon, didn't want to annoy too many Plex friends on the weekend. A few questions and also the latest logs in case this helps at all. I noticed the following after I captured those logs above. Is this common to see? Also, Maintainerr is disabled and turned off, why does it keep trying to find the icon still?

Jun 15 10:12:26 HADES kernel: vethd938b94: renamed from eth0

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethc148694) entered disabled state

Jun 15 10:12:26 HADES kernel: vethc148694 (unregistering): left allmulticast mode

Jun 15 10:12:26 HADES kernel: vethc148694 (unregistering): left promiscuous mode

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethc148694) entered disabled state

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered blocking state

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered disabled state

Jun 15 10:12:26 HADES kernel: vethd414c76: entered allmulticast mode

Jun 15 10:12:26 HADES kernel: vethd414c76: entered promiscuous mode

Jun 15 10:12:26 HADES kernel: eth0: renamed from vethcd44c90

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered blocking state

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered forwarding state

Jun 15 10:12:30 HADES webgui: Maintainerr: Could not download icon https://github.com/jorenn92/Maintainerr/blob/main/ui/public/logo.png?raw=true

5 minutes ago, wickedathletes said:

hades-diagnostics-20260614-1903.zip

I plan to start safe mode soon, didn't want to annoy too many Plex friends on the weekend. A few questions and also the latest logs in case this helps at all. I noticed the following after I captured those logs above. Is this common to see? Also, Maintainerr is disabled and turned off, why does it keep trying to find the icon still?

Jun 15 10:12:26 HADES kernel: vethd938b94: renamed from eth0

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethc148694) entered disabled state

Jun 15 10:12:26 HADES kernel: vethc148694 (unregistering): left allmulticast mode

Jun 15 10:12:26 HADES kernel: vethc148694 (unregistering): left promiscuous mode

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethc148694) entered disabled state

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered blocking state

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered disabled state

Jun 15 10:12:26 HADES kernel: vethd414c76: entered allmulticast mode

Jun 15 10:12:26 HADES kernel: vethd414c76: entered promiscuous mode

Jun 15 10:12:26 HADES kernel: eth0: renamed from vethcd44c90

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered blocking state

Jun 15 10:12:26 HADES kernel: br-35630357bbbc: port 7(vethd414c76) entered forwarding state

Jun 15 10:12:30 HADES webgui: Maintainerr: Could not download icon https://github.com/jorenn92/Maintainerr/blob/main/ui/public/logo.png?raw=true

This is docker service, you can ignore it unless it never ends, which could indicate a container boot looping.

My machine is roughly on 24 hours of uptime, so another 48-72 to go to see if I am in the clear when running in GUI Safe Mode however, I saw these in my log and was wondering if this was anything?

Jun 21 12:08:23 HADES ntpd[2650]: duplicate or replay: org 0xede28af7.2fc7a29a does not match 0x0.00000000 from [email protected]

Jun 21 12:09:27 HADES ntpd[2650]: duplicate or replay: org 0xede28b37.2fc80104 does not match 0x0.00000000 from [email protected]

Jun 21 12:09:37 HADES ntpd[2650]: duplicate or replay: org 0xede28b41.c8419670 does not match 0x0.00000000 from [email protected]

Jun 21 12:45:14 HADES ntpd[2650]: duplicate or replay: org 0xede2939a.c842c026 does not match 0x0.00000000 from [email protected]

still running strong, closing in on 48 hours now, so 1-2 days to go. That said, I noticed these 2 things in my log today:

Jun 22 10:19:33 HADES kernel: warning: `lshw' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211

Wasn't sure if either mattered or not.

Jun 23 07:32:15 HADES webgui: Successful login user root from 10.0.0.48

Jun 23 07:32:16 HADES nginx: 2026/06/23 07:32:16 [error] 5237#5237: *20763 open() "/usr/local/emhttp/apple-touch-icon-precomposed.png" failed (2: No such file or directory) while sending to client, client: 10.0.0.48, server: XYZ.myunraid.net, request: "GET /apple-touch-icon-precomposed.png HTTP/2.0", host: "XYZ.myunraid.net:3443"

I assume the above was caused by my attempt to login from my phone?

Edited June 23Jun 23 by wickedathletes

Probably, but should be harmless.

1 hour ago, JorgeB said:

Probably, but should be harmless.

and also this just popped up, and this is what i am concerned could be causing my crashing, as it degrades over time, then eventually all dockers die out.

Jun 23 09:57:20 HADES php-fpm[5126]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Edited June 23Jun 23 by wickedathletes

That should not cause issues other than the spam.

so i have done some debugging and figured I would check in with the latest logs (although I doubt it found it yet).

• I did 4 days in safe mode (no issues, it usually crashes between 2-3 days)

• I then left safe mode and did 3+ days of plugins only (no dockers) (no issues)

• I then did 3+ days of these dockers on: plex, radarr, radarr 4k (second instance), sab, sonarr, tautulli (no issues)

• I then added cloudflare, homarr, seerr, traefik and it stopped responding after 2 days

I am currently testing a different group of dockers with the original set that didn't have an issue. Assuming its one of those 4 dockers in the red line, but the only somewhat "new" docker is seerr and it was working fine. Eitherway, figured I would attach the logs in case anyone notices anything new. This whole, taking 2-3 days to stop responding thing is really annoying to debug. Is their any advanced logging I can turn on to help navigate the error better?

hades-diagnostics-20260706-1135.zip

I didn't see any evidence of this in previous diagnostics, but you might check rootfs usage occasionally in case a docker or something is filling up the OS space. This command line:

df -h /