Seit einiger zeit habe ich das Problem, dass ich mein Array nicht stoppen kann.

Ich habe schon versucht alle Docker und Vms zu stoppen bevor ich das Array stoppe ohne erfolg.

Diese Meldung steht unten links im Browser neben Array Stopping : Unmounting disks...Retry unmounting disk share(s)...

Nachdem dem ich mein Unraid Herunterfahre und Hochfahre kann ich das Array stoppen.

Ich habe meine Log file nach dem Herunterfahren gespeichert da ich gleesen habe das Unraid beim Herunterfahren das Array zwingt zu stoppen und dann ein fehler im Log speichert, nur verstehe ich nicht ganz wo ich den Fehler in den Logs finde^^

 

tower-diagnostics-20210527-2017.zip

30 minutes ago, BobbYYshkA said:

Seit einiger zeit habe ich das Problem, dass ich mein Array nicht stoppen kann.

Ich habe schon versucht alle Docker und Vms zu stoppen bevor ich das Array stoppe ohne erfolg.

Diese Meldung steht unten links im Browser neben Array Stopping : Unmounting disks...Retry unmounting disk share(s)...

Nachdem dem ich mein Unraid Herunterfahre und Hochfahre kann ich das Array stoppen.

Ich habe meine Log file nach dem Herunterfahren gespeichert da ich gleesen habe das Unraid beim Herunterfahren das Array zwingt zu stoppen und dann ein fehler im Log speichert, nur verstehe ich nicht ganz wo ich den Fehler in den Logs finde^^

Bitte prüfe ob du eine aktive SSH verbindung zum server offen hast und beende diese.

Normalerweise bedeuted dies das irgendetwas von "außen" per SSH noch auf dein System zugreift.

11 minutes ago, ich777 said:

Bitte prüfe ob du eine aktive SSH verbindung zum server offen hast und beende diese.

Normalerweise bedeuted dies das irgendetwas von "außen" per SSH noch auf dein System zugreift.

Nicht das ich wüsste... ausser es wird eine ssh Verbindung von einem Plugin oder Docker irgendwo hin erstellt...könnte das sein?
Kann man im Terminal abfragen ob es aktive ssh verbindungen hat?

Just now, BobbYYshkA said:

Nicht das ich wüsste... ausser es wird eine ssh Verbindung von einem Plugin oder Docker irgendwo hin erstellt...könnte das sein?

Nein normalerweise nicht.

War nur eine Vermutung da mir das schon ein paar mal passiert ist das ich eine SSH session oder SFTP session offen hatte zum server.

 

May 27 20:11:07 Tower emhttpd: Unmounting disks...
May 27 20:11:07 Tower emhttpd: shcmd (16169): umount /mnt/cache
May 27 20:11:07 Tower root: umount: /mnt/cache: target is busy.
May 27 20:11:07 Tower emhttpd: shcmd (16169): exit status: 32
May 27 20:11:07 Tower emhttpd: Retry unmounting disk share(s)...

 

Dieser Eintrag verrät dir das irgendwas noch auf /mnt/cache zugreift.

Läuft Unbalance noch im hintergrund oder wird evtl. noch eine Sicherung ausgeführt?

 

Kann es sein das dein Cache manchmal volläuft?

4 hours ago, ich777 said:

Nein normalerweise nicht.

War nur eine Vermutung da mir das schon ein paar mal passiert ist das ich eine SSH session oder SFTP session offen hatte zum server.

 

May 27 20:11:07 Tower emhttpd: Unmounting disks...
May 27 20:11:07 Tower emhttpd: shcmd (16169): umount /mnt/cache
May 27 20:11:07 Tower root: umount: /mnt/cache: target is busy.
May 27 20:11:07 Tower emhttpd: shcmd (16169): exit status: 32
May 27 20:11:07 Tower emhttpd: Retry unmounting disk share(s)...

 

Dieser Eintrag verrät dir das irgendwas noch auf /mnt/cache zugreift.

Läuft Unbalance noch im hintergrund oder wird evtl. noch eine Sicherung ausgeführt?

 

Kann es sein das dein Cache manchmal volläuft?

Unbalance ist Installiert aber nicht Aktiviert von daher denke ich nicht das es daran liegt.
Ja es kann schonmal vorkommen das der Cache volläuft hab den Mover über User Script auf 30min und 65% gestellt seither is es einmal vorgekommen wenn ich sehr viele Dateien kopiere oder verschiebe.

Dann kann ich zumbeispiel auch die Docker nicht mehr beenden oder neustarten und muss das ganze Unraid neustarten.

 

Hab ich keine chance irgenwo zusehen was da noch im Hintergrund lüft? Kann es sein das es am User Sript plugin liegt?

Wenn ich das Unraid neustarte kann ich das Array ja stoppen.

5 hours ago, BobbYYshkA said:

Kann es sein das es am User Sript plugin liegt?

Welche Scripte hast du laufen? Greift davon irgendwas auf deine Disks zu, insbesondere den Cache? Ich hatte dieses Problem schon, wenn:

- noch ein rsync Script lief

- der Mover noch aktiv war (= auch rsync)

- als ich mit einer Swap Datei herumgespielt hatte ^^

 

Bedenke: User Scripts hat einen Bug: Der Beenden Button unterbricht keine Scripte. Verstehe ich bis heute nicht, warum das nicht behoben wird. Ich hatte dazu schon vor langer Zeit einen Bugfix gepostet.

 

4 hours ago, BobbYYshkA said:

Hab ich keine chance irgenwo zusehen was da noch im Hintergrund lüft?

 

Ggfs. hilft Dir auf der Unraid Konsole "lsof | grep -i disk" oder "lsof | grep -i cache" oder "lsof | grep -i pool" um geöffnete Dateien zu finden. Da rauschen evtl. viele Zeilen durch und es dauert etwas. Schau mal ob in der Liste etwas als geöffnet aufgeführt ist, dass auf dem Array oder Cache/Pool liegt.

 

28 minutes ago, mgutt said:

Bedenke: User Scripts hat einen Bug: Der Beenden Button unterbricht keine Scripte. Verstehe ich bis heute nicht, warum das nicht behoben wird. Ich hatte dazu schon vor langer Zeit einen Bugfix gepostet.

 

Das ist mir auch bereits aufgefallen.

Habe bis dato dann immer über htop den entsprechenden Prozess gesucht und dann per pkill gestoppt. 

Gibt es hier eine elegantere Lösung?

1 hour ago, mgutt said:

Welche Scripte hast du laufen? Greift davon irgendwas auf deine Disks zu, insbesondere den Cache? Ich hatte dieses Problem schon, wenn:

- noch ein rsync Script lief

- der Mover noch aktiv war (= auch rsync)

- als ich mit einer Swap Datei herumgespielt hatte ^^

 

Bedenke: User Scripts hat einen Bug: Der Beenden Button unterbricht keine Scripte. Verstehe ich bis heute nicht, warum das nicht behoben wird. Ich hatte dazu schon vor langer Zeit einen Bugfix gepostet.

 

 

Ja, das Mover Script läuft, wie gesagt alle 30 min habe darauf geachtet, das es nicht läuft, bevor ich das Array stoppe.

Ein rsync Script hatte ich sicher auch mal laufen und mit dem "Abort Script" Button unterbrochen, wird sicher daran liegen, wenn das verbugt ist^^

 

Könntest vlt. dein Bugfix verlinken?

 

49 minutes ago, hawihoney said:

 

Ggfs. hilft Dir auf der Unraid Konsole "lsof | grep -i disk" oder "lsof | grep -i cache" oder "lsof | grep -i pool" um geöffnete Dateien zu finden. Da rauschen evtl. viele Zeilen durch und es dauert etwas. Schau mal ob in der Liste etwas als geöffnet aufgeführt ist, dass auf dem Array oder Cache/Pool liegt.

 

 

Danke für den Tipp werde ich mir merken und das nächste Mal testen.

 

39 minutes ago, Anym001 said:

 

Das ist mir auch bereits aufgefallen.

Habe bis dato dann immer über htop den entsprechenden Prozess gesucht und dann per pkill gestoppt. 

Gibt es hier eine elegantere Lösung?

 

Wenn ich mit "htop" die laufenden Prozesse auflisten kann und mit "pkill" stoppen, wäre das schon mal eine Zwischenlösung für mich.

 

 

Momentan läuft noch ein Pre Clear wenn das beendet ist, werde ich das mit dem rsync User Script noch mal testen und ggf der laufende Prozesse wie beschrieben beenden und mich noch mal melden.

 

Danke aufjedenfall für eure Hilfe

On 5/28/2021 at 8:34 AM, BobbYYshkA said:

Könntest vlt. dein Bugfix verlinken?

 

Ich habe ihm nur erklärt wie er das lösen kann. Umsetzen muss er das im Plugin selbst.

 

Bis dahin geht tatsächlich nur "pkill -xc rsync".

 

Ich habe mir einfach zur Vorsicht das folgende Script angelegt und als Ausführungsoption "At stopping of Array" ausgewählt:

#!/bin/bash
# x = exact match
# c = return process count
pkill -xc rsync

 

Ich bin mir ziemlich sicher, das es mit dem User Script und rsync zusammenhängt, da ich nicht wusste das, dass Script abbrechen über den Abort Button nicht funktioniert.

 

Das Script werde ich mir jedenfalls auch anlegen.

#!/bin/bash
# x = exact match
# c = return process count
pkill -xc rsync

Vielen Dank an jeden von euch 👍

 

Das Thema würde ich gerne nochmal hochholen. Ich habe derzeit die V7 von Unraid installiert und seit ein paar Tagen funktioniert das Stoppen des Arrays nicht mehr. Hat sich da in der Zwischenzeit etwas getan oder muss ich das mit dem gleichen User Script durchführen wenn es zu Problemen kommt?

Würde mich ebenfalls interessieren.

Habe auch teilweise Probleme mit dem Stoppen des Arrays.

Insbesondere schlecht, wenn es einen Stromausfall gibt, und die USV den Shutdown-Befehl gibt, aber das Array nicht gestoppt werden kann.

 

Laut Changelogs des User Scripts Plugin ist da was passiert:

2021.11.28
Fix abort scripts (Thanks @Noim)

 

Ist es also prinzipiell nicht mehr nötig, das Script von @mgutt laufen zu lassen?

On 2/1/2025 at 12:01 PM, saber1 said:

Ist es also prinzipiell nicht mehr nötig, das Script von @mgutt laufen zu lassen?

Ist nach wie vor kaputt.

 

Hier ein Test-Skript:

 

#!/bin/bash

# timestamping logs
exec &> >(stdbuf -o0 sed 's/%/%%/g' | xargs -d '\n' -I {} date '+%F %T {}')

echo "Start of script"

# long running command
tar -cv /mnt/disk1 | pv >/dev/null

echo "End of script"

 

Damit wird so getan als würde man was von Platte 1 woanders hin kopieren. Nun starte des Skript im Hintergrund. Dann breche ab. Im Dashboard siehst du nach wie vor, dass der mit voller Geschwindigkeit auf die Platte zugreift.

 

So kann man dann manuell stoppen:

pkill -xcf "tar -cv /mnt/disk1"

 

Das User Scripts Plugin hat auch einen Bug, dass wenn das Skript sehr lange läuft, dass es das gar nicht mehr anzeigt. Oder anders gesagt. PHP startet ja das Skript, läuft dann aber selbst irgendwann in ein Timeout. Das hat den ekligen Nebeneffekt, dass besonders lange laufende Skripte gerne mal mehrfach parallel laufen.

@mgutt

Danke Dir.

Ich nehme an, all die genannten Issues sind den entsprechenden Personen bekannt, aber es passiert in der Hinsicht einfach nichts?

dazu muss es sich aber auch um rsync handeln ...

 

bringt ja nichts rsync zu beenden wenn ein anderer task die Ursache wäre, rsync ist zwar gerne genommen (auch ich nutze dies in meinen plugins) aber das muss es ja nicht sein ... beispielsweise lsof hatte ich am Start für eines meiner plugins, um herauszufinden dass dies gerne mal "stalled" ... daher wurde dies auch bei UAD entfernt um gewissen Dinge abzufangen ...

 

will damit nur sagen, wenn es permanent bei einem zu issues führt, gezielt schauen welcher Prozess es ist und gezielt lösen.

 

entweder hart mit nem kill ... oder den workflow, ... überdenken.

FYI: Über Unassigned Devices hatte ich die Shares meines WD MyCloud NAS als NFS in Unraid eingebunden. (Zu backup Zwecken).

Hab mich dann entschieden die HDDs in Unraid einzubauen.

Hab dann das WD MyCloud NAS heruntergefahren ABER vorher vergessen, die mounts aus Unraid zu entfernen.

Unraid hat sich dann geweigert herunterzufahren.

Gab ein ähnliches Fehlerbild.

 

Hier ist der korrekte Vorgang:

- Zuerst externe mounts in unassigned devices unmounten

- dann externes NAS herunterfahren

- Optional (für Umzug): Die remoteshares entfernen

Edited February 25, 20251 yr by p0p

Meiner Ansicht nach fehlt in Unraid ein Einstellung, dass bei einem Shutdown jegliche Prozesse, die zB nach 5 Minuten noch auf den Shares hängen, einfach gekillt werden. Denn wenn eine leere USV dafür sorgt, dass der Server hart abschaltet, hat man ja auch nichts gewonnen.

Volle Zustimmung.

Das gehört ins OS integriert.

Insbesondere bei dem Beispiel mit einer USV.

Genau das hatte ich vor Kurzem.

 

Klar kann ich mich auch auf die Suche nach dem Übeltäter machen, und das dann irgendwie per Script (und als Trigger "At stopping of Array") managen.

Aber gerade wenn eine USV den Shutdown gibt, MUSS der Server herunterfahren. Egal was da noch läuft...

Dafür!

 

Hatte vor ein paar Tagen einen Stromausfall. Unraid ist so konfiguriert, dass es nach zwei Minuten unter USV Strom herunterfährt, da es dann in der Regel eine längere Angelegenheit wird (was es mit einer Stunde auch war).

 

Nur hat dann auch irgendeine Rsync Geschichte das unmounten der Disks blockiert. Da ich zuhause war, habe ich das mitbekommen und konnte dann noch eingreifen. Als ob am am Freitag Abend mit Stromausfall nicht schon genug gestraft wäre.  

 

Im Härtefall hätte die Kiste jedoch die USV leergelutscht, was im dümmsten Fall zum Datenverlust, im ägerlichen Fall nur zum unötigen Parity Check geführt hätte.

 

Dies ist in der Tat nicht sauber von Unraid gelöst.

Edited February 26, 20251 yr by Gorosch