Xerxes

Do you think it's related to that? When I have a minute, I'll try to change it

Back again. Now I stopped stopped docker service and vm mananger and after that the array does not stop. So I think it has nothing to do with the services. Correct me, if I'm wrong. When I start it an stop it like 2 h later it works great. Only if I want to stop it after about a week it hat no desire. I installed the zfs master plugin to see some snapshots. This one was huge! There are like 500-700 more lines. Does this look normal? The docker storage is set to native. This was recommended to me here in the forum. The server exists only for about four month and I have about 40 dockers. The command zfs list -r cache also shows all of these entries from above. I clean my server about every two weeks and shut it down for this purpose. It's never worked before for the server to shut down without errors after a few minutes. It always freezes at the exact same point. I've already tried the usual suspects, like fuser -mv /mnt/cache lsof /mnt/cache If I boot in safe mode, I can start and stop the array normally. I haven't tried it for a period longer than a week yet. What is the best way to proceed, considering that the error only occurs after a certain amount of time? Is there anything I can do to prevent this, like stopping before the array, to see if it will work? I'm currently trying a script that prepares everything, but it's not working. I keep getting the same error. #!/bin/bash echo "Starting array shutdown script..." ### 1. Unmount all SMB (CIFS) shares mounted on this server echo "Unmounting all SMB (CIFS) shares mounted on this server..." mount | grep -i cifs | awk '{print $3}' | while read -r share; do if [ -n "$share" ]; then echo "Unmounting $share" umount "$share" # Check if unmount was successful if mountpoint -q "$share"; then echo "Failed to unmount $share. Forcing unmount..." umount -l "$share" fi fi done ### 2. Stop all Docker containers echo "Stopping all Docker containers..." docker ps -q | xargs -r docker stop ### 3. Terminate SSH sessions accessing the array echo "Terminating SSH sessions accessing the array..." # Get the PID of the current script to avoid killing itself current_pid=$$ pids=$(lsof -t /mnt/disk* /mnt/user* 2>/dev/null | grep sshd | uniq | grep -v "^${current_pid}$") if [ -n "$pids" ]; then echo "Terminating SSH sessions with PIDs: $pids" echo "$pids" | xargs -r kill else echo "No SSH sessions accessing the array found." fi ### 4. Close any open files on the array echo "Closing any open files on the array..." pids=$(lsof -t /mnt/disk* /mnt/user* 2>/dev/null | uniq | grep -v "^${current_pid}$") if [ -n "$pids" ]; then echo "Terminating processes with PIDs: $pids" echo "$pids" | xargs -r kill else echo "No processes accessing the array found." fi ### 5. Stop VMs echo "Stopping all VMs..." virsh list --name | while read -r vm; do if [ -n "$vm" ]; then echo "Shutting down VM: $vm" virsh shutdown "$vm" # Initialize countdown max_wait=150 # Maximum wait time in seconds interval=10 # Interval between checks elapsed=0 while [ $elapsed -lt $max_wait ]; do sleep $interval elapsed=$((elapsed + interval)) echo "Checking if VM '$vm' has shut down... (Elapsed: ${elapsed}s)" if ! virsh list --name --state-running | grep -qw "^${vm}$"; then echo "VM '$vm' has shut down gracefully." break fi done # After timeout: force shutdown if virsh list --name --state-running | grep -qw "^${vm}$"; then echo "VM '$vm' did not shut down in time. Forcing shutdown..." virsh destroy "$vm" sleep 5 if ! virsh list --name --state-running | grep -qw "^${vm}$"; then echo "VM '$vm' has been forcefully terminated." else echo "Failed to forcefully terminate VM '$vm'. Manual intervention may be required." fi fi fi done ### 6. Stop SMB services echo "Stopping SMB services..." /etc/rc.d/rc.samba stop ### 7. Stop NFS services echo "Stopping NFS services..." /etc/rc.d/rc.nfsd stop ### 8. Stop additional services (optional) echo "Stopping additional services..." # Example: /etc/rc.d/rc.plexmediaserver stop Is this a known problem with any plugin?

Konntet ihr herausfinden, was das Problem war? Stehe aktuell vor der gleichen Herausforderung. Docker und VMs in den Einstellungen deaktiviert und trotzdem beim stoppen des Arrays bleibt es immer hängen bei Mar 28 12:21:21 nasgul emhttpd: Unmounting disks... Mar 28 12:21:21 nasgul emhttpd: shcmd (157761): /usr/sbin/zpool export -f cache Mar 28 12:21:21 nasgul root: cannot export 'cache': pool is busy Mar 28 12:21:21 nasgul emhttpd: shcmd (157761): exit status: 1 Mar 28 12:21:21 nasgul emhttpd: Retry unmounting disk share(s)... Die Infos unter "lsof", "cat /proc/mounts" zeigen keinen Zugriff mehr auf den Pool an. Userscripts sind alle gestoppt. Terminals alle geschlossen. Plugins, die ich installiert habe: Appdata Backup Community Applications Custom Tab Dynamix Active Streams (zeigt keine offenen Streams an) Dynamix Cache Directories (nach einer Deinstallation auch keine Besserung) Dynamix Safe Mode Dynamix Stop Shell Dynamix System Temperature Fix Common Problems GPU Statistics Intel GPU TOP Libvirt Hotplug USB mergerFS for UNRAID (fügt ein Dateisystem des Arrays mit meinem zweiten Cache zusammen. Beim Array-Stop liefert der Skript eine "0", schon vor erster Installation des Plugins traten o.g. Probleme auf) Nvidia Driver Python 3 for UNRAID Unassigned Devices Unassigned Devices Plus unbalanced (Nicht aktiviert) Unraid Connect Unraid Patch User Script (Kein Skript läuft mehr)

Bis jetzt keine Fehler mehr, nachdem ich alle C-States im BIOS deaktiviert habe. Dass nicht trotzdem der Server dauernd alle Kerne voll benutzt habe ich die P-Cores und die Hälfte der E-Cores für die VMs reserviert und diese sind in der syslinux.cfg nun isoliert. Die VMs, die diese Kerne nutzen, haben mit den Kernen keinerlei Probleme. Ich schließe mal daraus, dass es wohl an den C-States lag. Die 14. Gen i9 mag das wohl nicht.

I only did this so that I didn't have to force a restart while stopping the array. In operation, I wouldn't just do it like that

In my case I restart emhttpd and install the „shell stop“ plugin. Since then I do not have any issues stopping the array. But thats more like symptom supression than cause control. I'm not really satisfied, but it does what it's supposed to

Soo, eine neue CPU liegt seit Tagen hier, aber die alte hat das wohl mit bekommen und seit paar Tagen kein einziger Fehler mehr. Bis auf: Habe prime95 auf windows bare metal laufen lasse. Mehrere Stunden. Im Moment des Beendens bekomme ich ein BSOF und Windows schmiert ab. Für mich war das ein Zeichen, dass der Prozessor wohl keinen "Ruhezustand" mag und habe C-States komplett im BIOS deaktiviert. Habe nun auch die syslinux.cfg wieder auf deafult zurückgesetzt, sodass cpu4 auch wieder ran darf. Auch das ist nun soweit fehlerfrei. Bis jetzt. Sobald wieder Fehler kommen, werde ich doch mal die CPU tauschen.

No. To be sure that no extern processes were suspending my server I disconneced the lan-cable and pluged in a monitor.

Did that. System log is still flooded with these errors Feb 6 17:56:59 nasgul emhttpd: Unmounting disks... Feb 6 17:56:59 nasgul emhttpd: shcmd (229694): /usr/sbin/zpool export -f cache Feb 6 17:56:59 nasgul root: cannot export 'cache': pool is busy Feb 6 17:56:59 nasgul emhttpd: shcmd (229694): exit status: 1 Feb 6 17:56:59 nasgul emhttpd: Retry unmounting disk share(s)...

And for the moment? Restart the server by a hard-reset?

At the moment docker and docker daemon is not running. docker info Client: Version: 27.0.3 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.15.1 Path: /usr/libexec/docker/cli-plugins/docker-buildx Server: ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? errors pretty printing info /etc/rc.d/rc.docker status Docker daemon is not running. How can I stop my array safely now? I don't want to perform another hard shutdown using the reset button. Before hitting the "Stop Array" button in the GUI, I manually stop all containers to make sure that no container is using the cache.

I am now having the same problem in 7.0.0 stable. Unraid is now trying for more than an hour to export my chache. Down are my full diagnostics. Output of losetup was: NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzmodules 0 512 /dev/loop0 0 0 1 1 /boot/bzfirmware 0 512 so there are no other loops to unmount than these from unraid. output of zpool status cache was: zfs get mounted cache pool: cache state: ONLINE scan: scrub repaired 0B in 00:03:03 with 0 errors on Sat Jan 25 22:03:47 2025 config: NAME STATE READ WRITE CKSUM cache ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvme1n1p1 ONLINE 0 0 0 nvme0n1p1 ONLINE 0 0 0 errors: No known data errors NAME PROPERTY VALUE SOURCE cache mounted no - What else can I do to stop the array correctly? The error occurs with every array stop. You can ignore the corrected faults of the parity in the syslog attached. It's caused by a hard shutdown a couple of days ago. diagnostics-20250206-1226.zip

Kleines Update: RAM getauscht gegen Corsair Vengeance. Fehlercodes kamen weiterhin. Memtest, wie mit dem vorherigen RAM, unauffällig. Am kommenden Samstag wird eine "Ersatz-CPU" eingebaut für ein paar Tage. Seit dem ich isolcpus=4 als Notlösung zu der syslinux.cfg hinzugefügt habe, schaut alles stabil aus und es gibt keine Segfaults mehr. Scheint also wohl auf den ersten Blick tatsächlich ein defekter Kern zu sein. Sobald die neue (nicht) CPU funktioniert, werde ich nochmal Bescheid geben.

Tatsächlich nicht, aber: ich glaube auch, dass die Platten in Ordnung sind. Die eine Platte ist über ein SATA-Kabel, die andere über einen HBA mit einem SAS zu SATA-Kabel verbunden, deswegen würde ich die Kabel in dem Fall fast ausschließen (komplett andere Verbindungstechnik). Vor allem, da die Fehler im gleichen Moment kamen und beide Platten zu dem Zeitpunkt beschrieben wurden.

Hi, nachdem ich vor drei Tagen zwei HDDs zu meinem Array hinzugefügt hatte (beide an einem LSI 9207-8i angeschlossen), ist heute/vorhin auf einmal gleichzeitig bei zwei Platten der UDMA CRC Error Count auf "1" gewechselt. Ich habe gelesen, dass die mit hoher Wahrscheinlichkeit am Kabel oder am Controller liegt, jedoch ist eine Platte per Sata-Kabel direkt mit dem Mainboard (Intel Z790 Chip) verbunden, die andere über ein SFF-8087 Kabel mit dem LSI 9207-8i Controller. Beide Platten waren zu dem Zeitpunkt des Errors am beschreiben, also diese sind nicht gerade erst hochgedreht worden. Hängt dies mit einem höheren Problem, sprich z.B. Betriebssystem zusammen? Beide Platten, die den Error bekommen haben, waren Bestandsplatten, also nicht eine der beiden neuen. Wie kann ich das Problem elegant "ignorieren", ohne dass ich bei einer Status-Meldung über einen Messenger-Dienst nun jedes Mal eine Warnung bekomme und nicht alle paar Tage manuell den Counter überprüfen muss, falls ich den Error 199 einfach deaktiviere. Wenn ich im Dashboard die Meldung den Daumen nach unten bestätige, werden dann neue Fehler trotzdem angezeigt? Danke schonmal unraid-diagnostics-20250127-2040.zip