I just tried to stop the server using the Web interface. Now, it's stuck. I can't do anything. When I get to this point, what do I do? (I have to move the physical server, so I had to shut it down manually.)

Mine seems to go through phases -- the last few times, I've been able to shutdown with no issues. This time, I couldn't. I'm assuming something is running (though I don't know what).

2 hours ago, ctviggen said:

what do I do?

Start a new thread in General Support with your diagnostics and a description of your problem. Also setup syslog server.

Thanks. Somewhere in this thread was a recommendation to briefly press the power button, and unraid would attempt a clean shutdown. I did that, and unraid must have completed a clean shutdown, as it shutdown and after I got done moving everything and turned on the server, it came up without a parity check.

Follow-up to my earlier posts here about Reboot/Shutdown ending unclean while the mover, a btrfs scrub/balance or a ZFS scrub is running. I measured it on a 7.3.4 test VM and opened two webGui PRs as proofs of concept:

- https://github.com/unraid/webgui/pull/2809 : the GUI blocks Reboot, Shutdown and array Stop while such a job runs, names the job and says how to resolve it ("do it anyway" stays possible).

- https://github.com/unraid/webgui/pull/2810 : rc.local_shutdown clears those jobs before the timed array stop. This covers what the GUI can't block: UPS, power button, Ctrl-Alt-Del, command line.

Measured (Reboot from the GUI, one run each, pool disk throttled so the jobs last):

| Job running | Stock 7.3.4 | Patched |

|---|---|---|

| mover, 3 GB file | "Forcing shutdown..." after the 90 s timeout | 32 s, clean |

| btrfs scrub | forced, unclean, parity check at boot | 33 s, clean |

| btrfs balance | forced, unclean, parity check at boot | 35 s, clean |

What's actually going on:

- Stop is disabled during parity/mover/btrfs operations, but Reboot and Shutdown check nothing. ZFS scrub isn't handled at all, not even for Stop.

- The mover can't simply be stopped. The current file is copied inside shfs, so mover stop and even kill -9 on move don't end it. The user share stays busy until that file is complete, and with a big file that's longer than any sensible timeout. Ending that copy leaves the source intact and a .partial file on the array, which the next mover runs clean up.

- Every shutdown path ends in the same single timed array stop in rc.local_shutdown. Nothing in it stops the mover or cancels a scrub or balance.

Why it matters more every year: I found 19 public reports of timed-out or unclean shutdowns since 2016. In 10 of them the answer was "raise the shutdown timeout". The default is still 90 s, it's one fixed value for every system and every running job, and on a UPS it is capped by the battery anyway. Meanwhile drives keep growing (Seagate's average shipped capacity went from 7.3 TB to 13 TB between late 2022 and mid-2025). So the forced parity check after an unclean shutdown now takes a day or more once the largest disk is 14 TB or larger. Sources, timeline and the reports themselves are in the PR descriptions.

The PRs are meant to show that this is reproducible and fixable with small changes. Whether Lime Technology takes them or does it better, I'd mostly like to know why it has stayed open this long.