csb

I'm pretty sure the Libation template is currently incompatible with the semi-recent "breaking changes" made to its Docker: https://github.com/rmcrackan/Libation/blob/master/Documentation/Docker.md I believe it runs as the wrong user and group (should run as 99:100 on Unraid, but runs as 1001:1001). "-u 99:100" under extra parameters fixes it, somewhat ... the UMASK is still wrong and written files can't be edited via SMB. No idea how to fix UMASK, though.

Ha! I think I just managed to reproduce/trigger the bug intentionally: I had two tabs open, Main and Docker in Firefox. I restarted nginx while they were open and the whole mess is starting all over again instantly. Syslog is filling up with "nginx: worker process ... exited on signal 6" albeit slower than before ("only" about one entry every two seconds) and shared memory used keeps filling up rapidly. This time, simply closing the tabs made the log entries stop. Again, shared memory filled up to several megabytes and is showing no signs of freeing up the already used memory. But it's now hovering at the amount where it was when the tabs were closed. So far, a viable workaround is: close browser, ssh into server, restart nginx, reopen browser after. Maybe nginx was restarted by the server last night and all hell broke loose when my PC resumed from standby with the old tabs still open? Isn't there something that can be done to prevent this? diagnostics.zip

I think I just caught the bug in the act. Unraid 7.0.0 stable with latest patches. Firefox 135 (although I'm still pretty sure this is a browser-agnostic bug, I'm reasonably certain that observed the same thing with Chrome previously). At least the docker tab was left open last night (not sure if there were others), and I resumed my system from standby (as described several times here, that seems to be the, or at the very least a, trigger). The UI slowly started to fail and started throwing error (community apps kept randomly failing to communicate with the Unraid Server, for example) and is now entirely broken, I can't open syslog via the UI (the popup window closes instantly and opening the URL directly throws a 502 Bad Gateway). The interesting thing that I noticed: The bug isn't caused by nginx running eventually out of shared memory, the bug is causing nginx to run out of shared memory. nchan_stub_status when I started typing this: total published messages: 2862057 stored messages: 2 shared memory used: 7356K shared memory limit: 131072K channels: 7 subscribers: 2 redis pending commands: 0 redis connected servers: 0 redis unhealthy upstreams: 0 total redis commands sent: 0 total interprocess alerts received: 0 interprocess alerts in transit: 0 interprocess queued alerts: 0 total interprocess send delay: 0 total interprocess receive delay: 0 nchan version: 1.3.7 nchan_stub_status a couple of minutes later: total published messages: 2862831 stored messages: 1 shared memory used: 13204K shared memory limit: 131072K channels: 5 subscribers: 1 redis pending commands: 0 redis connected servers: 0 redis unhealthy upstreams: 0 total redis commands sent: 0 total interprocess alerts received: 0 interprocess alerts in transit: 0 interprocess queued alerts: 0 total interprocess send delay: 0 total interprocess receive delay: 0 nchan version: 1.3.7 It's currently rapidly filling up shared memory - but the UI is already (mostly) broken. Another minute later (all tabs closed, except for nchan_stub_status): total published messages: 2863246 stored messages: 0 shared memory used: 16228K shared memory limit: 131072K channels: 6 subscribers: 3 redis pending commands: 0 redis connected servers: 0 redis unhealthy upstreams: 0 total redis commands sent: 0 total interprocess alerts received: 0 interprocess alerts in transit: 0 interprocess queued alerts: 0 total interprocess send delay: 0 total interprocess receive delay: 0 nchan version: 1.3.7 It looks like "shared memory used" keeps growing faster than in the beginning. Less than a minute later: total published messages: 2863626 stored messages: 1 shared memory used: 18776K shared memory limit: 131072K channels: 5 subscribers: 1 redis pending commands: 0 redis connected servers: 0 redis unhealthy upstreams: 0 total redis commands sent: 0 total interprocess alerts received: 0 interprocess alerts in transit: 0 interprocess queued alerts: 0 total interprocess send delay: 0 total interprocess receive delay: 0 nchan version: 1.3.7 I just SSHed into the server, this how the syslog looks while it is happening: Feb 6 08:42:11 Bob nginx: 2025/02/06 08:42:11 [alert] 11264#11264: worker process 3365625 exited on signal 6 Feb 6 08:42:11 Bob nginx: 2025/02/06 08:42:11 [alert] 11264#11264: worker process 3365684 exited on signal 6 Feb 6 08:42:11 Bob nginx: 2025/02/06 08:42:11 [alert] 11264#11264: worker process 3365788 exited on signal 6 Feb 6 08:42:11 Bob nginx: 2025/02/06 08:42:11 [alert] 11264#11264: worker process 3365791 exited on signal 6 Feb 6 08:42:12 Bob nginx: 2025/02/06 08:42:12 [alert] 11264#11264: worker process 3365858 exited on signal 6 Feb 6 08:42:12 Bob nginx: 2025/02/06 08:42:12 [alert] 11264#11264: worker process 3365966 exited on signal 6 Feb 6 08:42:12 Bob nginx: 2025/02/06 08:42:12 [alert] 11264#11264: worker process 3365967 exited on signal 6 Feb 6 08:42:12 Bob nginx: 2025/02/06 08:42:12 [alert] 11264#11264: worker process 3365972 exited on signal 6 Feb 6 08:42:13 Bob nginx: 2025/02/06 08:42:13 [alert] 11264#11264: worker process 3365973 exited on signal 6 Feb 6 08:42:13 Bob nginx: 2025/02/06 08:42:13 [alert] 11264#11264: worker process 3366024 exited on signal 6 EDIT: Ok, some more interesting observations: Running /etc/rc.d/rc.nginx restart did not resolve the bug. It, naturally, reset nginx and freed up shared memory, but it was rapidly filling up again and syslog was still throwing multiple "nginx: worker process ... exited on signal 6" per second. Closing all open Firefox tabs to Unraid (in fact, all but this forum post) did not resolve the issue. Simply restarting Firefox made the whole thing stop instantly. No more log entries. However, this did not clear up nginx shared memory - it's now hovering at the last number where it was when I restarted Firefox: total published messages: 2707 stored messages: 18 shared memory used: 1404K shared memory limit: 131072K channels: 16 subscribers: 7 redis pending commands: 0 redis connected servers: 0 redis unhealthy upstreams: 0 total redis commands sent: 0 total interprocess alerts received: 0 interprocess alerts in transit: 0 interprocess queued alerts: 0 total interprocess send delay: 0 total interprocess receive delay: 0 nchan version: 1.3.7

It just happened to me in 7.0.0-beta4. Exact same behavior and error log. Gave me quite an adrenalin rush to see the array entirely unpopulated in the broken web-gui.

Exact same problem here today (7.00-beta4). It was terrifying to see the array unpopulated inside the broken web-gui. Dozens of threads across dozens of Unraid versions describing the exact same issue, no real solution. Is anyone looking into this?

Sorry, I'm struggling to follow that comment. What should I rsync here? This is about the removal of an empty (but not zeroed) drive, can you explain how I can use rsync to restore parity? Is there any documentation you could point me towards? But ... that's simply not true, or is it? That's the whole point of method three: With a full rebuild, parity will be marked as invalid until all 12Tb of parity have been rewritten, with check and correct it will always remain marked valid and will actually be valid after the 4Tb have been corrected. Or is there some upper sync error limit that invalidates parity that I'm not aware of? What I understand from the documentation so far: Sync errors explicitly do not invalidate parity. If the checkbox is checked, sync errors are corrected immediately (even before logging them). There's an upper limit for logging sync errors (100), so syslog flooding shouldn't be an issue (and there's a decent chance that performance picks up as well). Parity shouldn't be marked invalid at any point. Technically, I could cancel the check/correct run after the first 4TB and parity would be valid and Unraid would happily accept it as valid, but it's sensible to finish the entire check. What am I not seeing here?

The total time doesn't really matter, though, does it? The only thing that would matter is the time it would take to rebuild or rather "correct" the 4Tb of parity data that's actually mismatched vs the full parity rebuild. If the check runs on beyond those 4Tb that's fine and desirable, but it shouldn't find any more errors to correct at that point. Once the 4Tb of parity data have been "corrected", the Array is properly redundant again. As to the performance difference, it would have to be significantly more than three times slower for method one to be preferable. In my previous experience, the difference in time for a check and a rebuild has been minimal at best - but, admittedly, a check never had to correct more than a couple of sync errors as a result of a dirty shutdown, so it's certainly possible that correcting that much data would be much slower than rebuilding it.

I'm thinking of removing a slow and small drive from my significantly larger Array. The official documentation lists two methods for shrinking the Array: https://docs.unraid.net/unraid-os/manual/storage-management/ The officially supported method: "New Config" -> remove drive -> rebuild parity in full The second, documented, but not officially supported, method: Zero the to-be-removed drive via an unsupported, no longer maintained and no longer compatible/functional userscript (alternative: manually dd the drive to zero and/or manually fix the broken userscript) -> New Config -> remove the drive -> claim parity is still valid The first method leaves the Array fully unprotected during the parity rebuild (for multiple days, depending on HDD size and speed), the unsupported method relies on one's skill and self-confidence to zero the correct drive via dd and/or trust in an old and broken userscript and one's ability to correctly fix it. But wouldn't there be a third possible method as a theoretically-safer-than-the-official-method middle ground? Proposal: "New Config" -> remove drive -> check "parity already valid" (even though it, partially, isn't) -> check and correct parity. This would list and correct sync errors until the size of the removed disk has been reached, but beyond that point parity should be valid and safe, right? That means if I remove e.g. a 4Tb drive from an Array with 12Tb of parity data, the parity would only be in an unsafe/invalid state for the first 4Tb of the check and correction process - which would mean that parity protection already kicks back in after a couple of hours instead of after a couple of days. Does anyone see an obvious flaw in this method or my understanding of Unraid?

To make it short, looks like my cheap, but reasonably well reviewed, PSU just died. The server gently clicks once when I plug it in and draws 3W, but that's all it does. So I hope that the most likely culprit is the actual culprit here (any advice for further troubleshooting is welcome). Normally, the server draws about ~30W in idle from the wall (with the old, not super-efficient, PSU), and has never exceeded 220W under full load. It's an Intel i5-11400 on a Gigabyte B560M DS3H V2 with 32Gb RAM, an ASM 1166 SATA-extender card, 12 SATA drives and 2 M.2 SSDs. The enclosure is a Fractal Node 804 and I would prefer another ATX PSU as a drop-in replacement over fiddling with a Pico PSU. The once highly recommended Corsairs RMx550 v2 is in short supply here in Germany and, naturally, energy prices are high. What's the PSU with the best efficiency at around 30W, that also won't break the bank? Modular is a plus (for repairability) but not a must.

Ich weiß, der Thread ist schon etwas älter, aber da es hier keine Lösung gibt, zumindest ein paar zusätzliche Details: Meines Wissens liegt hier ein Firefox-Bug vor. Unter Proxmox gibt's den gleichen Fehler: https://bugzilla.proxmox.com/show_bug.cgi?id=1471 Eine echte Lösung, außer für VNC auf einen Chromium-basierten Browser auszuweichen, habe ich bisher nicht gefunden.

Good to hear, hope to see that addressed soon.

I know I'm not the only one who was stumped to find out that the baked in memtest tool in Unraid's boot menu doesn't support UEFI systems and fails to launch. But the general reason given for this has been wholly unsatisfactory. Supposedly, Unraid is shipping with an old version of Passmark's memtest86 and a license change prevents any further updates? At least that's what I read. Why is Unraid shipping with Passmark's closed source memtest86 at all instead of the excellent, fully rewritten, actively developed and 100% open source memtest86+ v6? https://github.com/memtest86plus/memtest86plus https://memtest.org Any reason why Unraid can't bundle this memtest tool? Should be trivial and would prevent a lot of "why is memtest broken?" forum posts.