Unclean shutdown detected - unmount /mnt/nvme-cache -> exit status 32 "target is busy"

haeknp3nnr · June 30, 2022

Moin Leute,

wie der Titel schon sagt, bekomme ich jedes mal beim Stoppen des Arrays / Herunterfahren - Starten / Neustart die o.g. Fehlermeldung und er beginnt nach dem Hochfahren seine Paritätsprüfung.

- die Timeouts für Docker / VMs / Disks habe ich gemäß diesem Thread gesetzt

- Tipps & Tweaks "Processes to kill before Array is Stopped" -> ssh,bash

Versuche ich manuell das Array zu stoppen, um das Log voll zu bekommen erhalte ich folgendes:

Jun 30 09:29:20 unraid emhttpd: shcmd (1558): umount /mnt/nvme-cache
Jun 30 09:29:20 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:20 unraid emhttpd: shcmd (1558): exit status: 32
Jun 30 09:29:20 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:25 unraid emhttpd: Unmounting disks...
Jun 30 09:29:25 unraid emhttpd: shcmd (1559): umount /mnt/nvme-cache
Jun 30 09:29:25 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:25 unraid emhttpd: shcmd (1559): exit status: 32
Jun 30 09:29:25 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:30 unraid emhttpd: Unmounting disks...
Jun 30 09:29:30 unraid emhttpd: shcmd (1560): umount /mnt/nvme-cache
Jun 30 09:29:30 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:30 unraid emhttpd: shcmd (1560): exit status: 32
Jun 30 09:29:30 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:35 unraid emhttpd: Unmounting disks...
Jun 30 09:29:35 unraid emhttpd: shcmd (1561): umount /mnt/nvme-cache
Jun 30 09:29:35 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:35 unraid emhttpd: shcmd (1561): exit status: 32
Jun 30 09:29:35 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:40 unraid emhttpd: Unmounting disks...
Jun 30 09:29:40 unraid emhttpd: shcmd (1562): umount /mnt/nvme-cache
Jun 30 09:29:40 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:40 unraid emhttpd: shcmd (1562): exit status: 32
Jun 30 09:29:40 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:45 unraid emhttpd: Unmounting disks...
Jun 30 09:29:45 unraid emhttpd: shcmd (1563): umount /mnt/nvme-cache
Jun 30 09:29:45 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:45 unraid emhttpd: shcmd (1563): exit status: 32
Jun 30 09:29:45 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:50 unraid emhttpd: Unmounting disks...
Jun 30 09:29:50 unraid emhttpd: shcmd (1564): umount /mnt/nvme-cache
Jun 30 09:29:50 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:50 unraid emhttpd: shcmd (1564): exit status: 32
Jun 30 09:29:50 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:29:55 unraid emhttpd: Unmounting disks...
Jun 30 09:29:55 unraid emhttpd: shcmd (1565): umount /mnt/nvme-cache
Jun 30 09:29:55 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:29:55 unraid emhttpd: shcmd (1565): exit status: 32
Jun 30 09:29:55 unraid emhttpd: Retry unmounting disk share(s)...
Jun 30 09:30:00 unraid emhttpd: Unmounting disks...
Jun 30 09:30:00 unraid emhttpd: shcmd (1566): umount /mnt/nvme-cache
Jun 30 09:30:00 unraid root: umount: /mnt/nvme-cache: target is busy.
Jun 30 09:30:00 unraid emhttpd: shcmd (1566): exit status: 32
Jun 30 09:30:00 unraid emhttpd: Retry unmounting disk share(s)...

... und das bis er umfällt bzw. die Timeout´s übersteigt und kein graceful shutdown möglich ist ! Im Log auf dem Flash Stick steht leider auch nur "unclean shutdown detected" und das er versucht hat die disk zu unmounten.

Aus dem angehängten syslog von gestern Abend sieht man, dass er um 22:44 Uhr angefangen hat zu "unmounten"

Jun 29 22:44:35 unraid emhttpd: shcmd (219910): umount /mnt/cache-nvme
Jun 29 22:44:35 unraid root: umount: /mnt/cache-nvme: target is busy.
Jun 29 22:44:35 unraid emhttpd: shcmd (219910): exit status: 32
..........

..........

Jun 29 23:01:46 unraid root:                      root      31041 .rce. ttyd
Jun 29 23:01:46 unraid root: /mnt/cache-nvme:     root     kernel mount /mnt/cache-nvme
Jun 29 23:01:46 unraid root:                      root      20968 ..c.. mc
Jun 29 23:01:46 unraid root: /mnt/disks:          root     kernel mount /mnt/disks
Jun 29 23:01:46 unraid root: /mnt/remotes:        root     kernel mount /mnt/remotes
Jun 29 23:01:46 unraid root: /mnt/rootshare:      root     kernel mount /mnt/rootshare
Jun 29 23:01:46 unraid root: Active pids left on /dev/md*
Jun 29 23:01:46 unraid root: Generating diagnostics...
Jun 29 23:01:50 unraid emhttpd: Unmounting disks...
Jun 29 23:01:50 unraid emhttpd: shcmd (220121): umount /mnt/cache-nvme
Jun 29 23:01:50 unraid root: umount: /mnt/cache-nvme: target is busy.
Jun 29 23:01:50 unraid emhttpd: shcmd (220121): exit status: 32
Jun 29 23:01:50 unraid emhttpd: Retry unmounting disk share(s)...

... dann ist das Log zu Ende und unraid hat heruntergefahren.

Habt Ihr Ideen ?

Besten Dank im voraus & Grüße

syslog.txt

Revan335 · July 2, 2022

Hast du vielleicht noch Plugins, Skripte, Konsolen, Sessions oder irgendwelche Operationen die ggf. noch was auf dem Cache offen halten und er deshalb nicht ausgehangen werden kann?

mgutt · July 2, 2022

Du könntest so suchen was auf den Pfad zugreift:

lsof | grep /mnt/cache-nvme

haeknp3nnr · July 3, 2022

14 hours ago, Revan335 said:

Hast du vielleicht noch Plugins, Skripte, Konsolen, Sessions oder irgendwelche Operationen die ggf. noch was auf dem Cache offen halten und er deshalb nicht ausgehangen werden kann?

nicht das ich wüsste ! Ich kann auch vorher manuell alle Docker / VMs etc. beenden, den Mover manuell laufen lassen und dann das Array manuell stoppen ... gleiches Fehlerbild

14 hours ago, mgutt said:
Du könntest so suchen was auf den Pfad zugreift:
lsof | grep /mnt/cache-nvme

der Befehl zeigt Nichts an

Habe die NVME bereits mal aus dem "Cache-Pool" geschmissen und als einzelne Disk via "unassigned devices" eingebunden. Auch hier beim Versuch das hinterher zu unmounten folgende Meldung - und es es Nichts auf der Platte / kein Dienst ist konfiguriert hierauf zuzugreifen:
image.png.fe94e71d27a60adf5a1dc5aeeae9b9c8.png image.png.a8ba10215d4addfcf690bf93597e71fd.png

mgutt · July 3, 2022

Welche NVMe ist das? Wenn du länger wartest, kannst du dann später noch darauf Dateien erstellen? Es wirkt ja irgendwie so, als sei die NVMe "weg". Also würde nicht mehr auf den umount reagieren.

haeknp3nnr · July 3, 2022

das ist die "nvme-cache", welche ich testweise aus dem Cache-Pool genommen, dann als Disk-Share per unassigned Devices eingebunden habe.

mgutt · July 12, 2022

36 minutes ago, haeknp3nnr said:
root: umount: /mnt/cache-nvme: target is busy

Du musst herausfinden was alles in dieses Verzeichnis schreiben darf.

Hast du zB rsync in Nutzung oder selbst unterhalb dieses Verzeichnisses manuelle Mounts erstellt?

Wobei mir dieser Teil komisch vorkommt:

Jun 29 22:44:27 unraid emhttpd: shcmd (219884): /etc/rc.d/rc.docker stop
Jun 29 22:44:27 unraid root: "docker stop" requires at least 1 argument.
Jun 29 22:44:27 unraid root: See 'docker stop --help'.
Jun 29 22:44:27 unraid root: 
Jun 29 22:44:27 unraid root: Usage:  docker stop [OPTIONS] CONTAINER [CONTAINER...]
Jun 29 22:44:27 unraid root: 
Jun 29 22:44:27 unraid root: Stop one or more running containers
Jun 29 22:44:27 unraid root: stopping dockerd ...
Jun 29 22:44:28 unraid root: waiting for docker to die ...

Das aufgeführte Skript /etc/rc.d/rc.docker ermittelt alle vorhandenen Container:

docker ps --format='{{.Names}}'

und stoppt sie dann:

docker stop $(running_containers)

In deinem Fall scheint es so zu sein, als würde das erste Kommando keine oder ungültige Containername zurückgeben. Kannst du das mal bitte testen?

haeknp3nnr · July 24, 2022

Moin Moin,

würde ich gerne ausprobieren, nur "leider" tritt der Fehler nun nicht mehr auf.

Thema ist erst einmal durch. Würde deine Tipps durchgehen, wenn es wieder hochkommt.

Besten Dank und viele Grüße

haeknp3nnr · August 1, 2022

Mahlzeit ! Es ist nun doch mal wieder soweit ....

image.png.0453d246ff9a7f69e74516f194dc45df.png

der Midnight-Commander hängt sich in regelmäßigen Abständen auf und bleibt dann im Hintergrund auf das Share aktiv

Schieße ich das Ganze per kill %pid% stopped das Array normal.

Bekomme ich das halbwegs unkompliziert als Cron-Job als Trigger bei "ArrayStop / Shutdown / Restart" hinterlegt oder hat jemand eine Idee, warum sich der MC ständig weghängt ?

hawihoney · August 1, 2022

4 hours ago, haeknp3nnr said:

der Midnight-Commander hängt sich in regelmäßigen Abständen auf

Was machst Du denn damit? Es gibt doch nichts Ausgereifteres als dieses Werkzeug. Das hängt sich nicht so einfach auf. Und unter normalen Umständen muss auch niemand mit lsof, kill und Konsorten arbeiten.

Also meine Frage: Du startest eine Konsole, Du startest den MC und was machst Du dann? Du kopierst was/wieviel von Quelle nach Ziel. Wie lauten die Beiden?

Und dann passiert was? Arbeitest Du mit screen bei längeren Kopierarbeiten? Und wenn Du mit screen arbeiten solltest, beendest Du zum Schluss auch ordentlich beide (!) Sessions?

Nimm doch testweise Mal den Dynamix File Manager als Alternative.

mgutt · August 4, 2022

On 8/1/2022 at 10:13 AM, haeknp3nnr said:

warum sich der MC ständig weghängt ?

Steht nichts in den syslogs?

Und warum überlebt er es, wenn du das Terminal schließt 🤔

On 8/1/2022 at 10:13 AM, haeknp3nnr said:

Bekomme ich das halbwegs unkompliziert als Cron-Job als Trigger bei "ArrayStop / Shutdown / Restart" hinterlegt

Wäre denkbar, aber auf halt so ein Workaround den keiner wirklich will.

Welche unRAID Version?

haeknp3nnr · August 29, 2022

On 8/4/2022 at 6:41 PM, mgutt said:

Steht nichts in den syslogs?

Ich kann leider Nicht erkennen. Was ich aber feststelle, ist, dass sowohl das unRAID Webterminal als auch andere SSH-Clients wie putty / xshell nach einer gewissen Zeit einen "reset" durchführen und die Verbindung vom "foreign host" geschlossen wurde - letzteres sehe ich nur über SSH-Clients.

Starte ich den MC also per Webterminal / %random SSH-Client% und z.B. einen Kopier-/Move-Vorgang per MC ist die Session nach X-Zeit "weg", jedoch noch im Hintergrund irgendwo aktiv und das blockiert das Herunterfahren bzw. verursacht dieses Verhalten (unclean shutdown)

Hier ein Beispiel aus xshell. Das Verhalten tritt jedoch genauso auch beim Webterminal oder putty auf.

Konnte mir bis dato damit behelfen, dass ich den MC einfach nicht benutze - was ich aber schade find.

@mgutt: Gefühlt tritt dieses Verhalten mit dem Zwangsreset der SSH-Sessions seit Update auf die 6.10.x auf ! Laufe aktuell auf der 6.10.3. Habe auch schon im Menü geschaut, ob ich etwas zu solchen Timeout Settings finde ... jedoch konnte ich das nicht.

Hier ein Video von jemandem auf reddit, der das gleiche Verhalten auffindet

On 8/1/2022 at 3:17 PM, hawihoney said:

Was machst Du denn damit? Es gibt doch nichts Ausgereifteres als dieses Werkzeug. Das hängt sich nicht so einfach auf. Und unter normalen Umständen muss auch niemand mit lsof, kill und Konsorten arbeiten.

Also meine Frage: Du startest eine Konsole, Du startest den MC und was machst Du dann? Du kopierst was/wieviel von Quelle nach Ziel. Wie lauten die Beiden?

Terminal -> "mc" -> Kopier- oder Moves von Dateien/Ordnern ... mal kleine ... mal große ! Nix wildes - simples using

On 8/1/2022 at 3:17 PM, hawihoney said:

Und dann passiert was? Arbeitest Du mit screen bei längeren Kopierarbeiten? Und wenn Du mit screen arbeiten solltest, beendest Du zum Schluss auch ordentlich beide (!) Sessions?

Da passiert, dass die Webterminal Session "resetted/reconnected" wird bzw. die connection vom foreign host geclosed wird. Ordentlich schließen würde ich ja gerne. Jedoch ist Session schon vorher frozen und dann weg.

Gorosch · August 29, 2022

Hast du schon mal die Verbindung zwischen deinem PC und Unraid überprüft, ob die durchgehend sauber arbeitet?

hawihoney · August 29, 2022

1 hour ago, haeknp3nnr said:

Terminal -> "mc" -> Kopier- oder Moves von Dateien/Ordnern ... mal kleine ... mal große ! Nix wildes - simples using

Nur aus Interesse da Du meine Frage zu screen nicht beantwortet hast: Die SSH Sessions mit den Kopier- oder Verschiebeaktionen laufen etwas länger? Wenn ja, ist der MC in einer eigenen "screen" Session vor Unterbrechung der SSH Session geschützt?

Edited August 29, 2022 by hawihoney

haeknp3nnr · August 29, 2022

Die Netzwerkverbindung ist´s nicht. Gleiches Verhalten per LWL & Mgmt-LAN ... keine Paketverluste. Alle anderen Dienste arbeiten sauber.

hawihoney · August 29, 2022

55 minutes ago, haeknp3nnr said:

Die Netzwerkverbindung ist´s nicht.

Vorne anfangen! Hast Du screen auf dem Unraid Server laufen? Dann:

- starte eine SSH Session mit Putty oder was immer Du willst

- gib "screen" ein und bestätige die erscheinende Textseite mit Enter

- gib folgende Tastenkombination ein <CTRL-a c>

- gib "mc" ein

- Lass das so laufen

- Wenn die Session einfriert (Du könntest das SSH Fenster auch einfach schließen), dann starte anschließend eine neue SSH Session

- Gib "screen -ls" ein. Jetzt siehst Du eine Liste Deiner laufenden Screen Session. Das müsste die mit Deinem MC sein

- Mit "screen -r" bekommst Du diese Session zurück

--> Jetzt die entscheidende Frage: Siehst Du das MC Fenster. Das kannst Du dann mit F10 schließen. Und mit 2x "exit" beendest Du die Screen Session sowie die SSH Session.

Edited August 29, 2022 by hawihoney

haeknp3nnr · August 29, 2022

- screen installiert

-> gemacht wie beschrieben ! Funktioniert - ich bekomme die MC Session wieder !

Besten Dank hierfür !!!!!!

Hab mal die Zeit gestoppt. Nach exakt 20 Sekunden wird das Webterminal-Fenster resetted. Das timeout/den reconnect muss man doch iwo als Wert setzen können ?

hawihoney · August 29, 2022

13 minutes ago, haeknp3nnr said:

Funktioniert

Jetzt kannst Du mit diesem Wissen schon mal problemlos mit SSH Sessions arbeiten. Darfst nur nicht vergessen abschließend ordentlich alles zu beenden. Sonst fährt Unraid nicht runter.

Was Deine Timeouts angeht: Ist das ein Laptop oder Mobilgerät? Wenn ja, passiert das auch wenn das Gerät am Strom steckt?

Zu Timeout Einstellungen: Das stellt man im Klienten ein. In Putty hier. Das bringt aber alles nichts wenn der PC mit der Session in den Stromsparmodus geht oder einfach abschaltet.

image.png.2ea46f144ca575efaf05f5518996970f.png

Edited August 29, 2022 by hawihoney

haeknp3nnr · August 30, 2022

15 hours ago, hawihoney said:

Was Deine Timeouts angeht: Ist das ein Laptop oder Mobilgerät? Wenn ja, passiert das auch wenn das Gerät am Strom steckt?

wie oben geschrieben, reißt mir die Verbindung vom unRAID Webterminal ttyd auch bereits nach 20-30 Sekunden ab. So schnell geht auch kein Laptop in die PowerStates / Standby ... ist zu dem ein stationärer PC ohne solche Energiefeatures.

15 hours ago, hawihoney said:

Zu Timeout Einstellungen: Das stellt man im Klienten ein. In Putty hier. Das bringt aber alles nichts wenn der PC mit der Session in den Stromsparmodus geht oder einfach abschaltet.

Tut er nicht - sonst würde ich hier nicht so einen Fred aufmachen ! Es ist weder die Netzwerkverbindung noch das Session-Timeout des SSH Clients. Das keep-alive der SSH Clients funktioniert (On/Off - Gegenprobe mit verschiedenen Zeiten als Trigger probiert). Jedoch ist das Abreißen/Refresh/Reconnect der Terminal-Oberfläche vom Server (unRAID) initiiert.

Egal welcher Browser (unRAID Webterminal ttyd - nach 20-30 Sekunden sind die Eingaben "weg" und das Terminal leer). Bei den SSH Clients dauert etwas länger.

hawihoney · August 30, 2022

16 minutes ago, haeknp3nnr said:

wie oben geschrieben, reißt mir die Verbindung vom unRAID Webterminal ttyd auch bereits nach 20-30 Sekunden ab. So schnell geht auch kein Laptop in die PowerStates / Standby

Dann muss es tatsächlich etwas Anderes sein. Steht irgendein Hinweis in der Datei dead.letter im Webterminal?

Unclean shutdown detected - unmount /mnt/nvme-cache -> exit status 32 "target is busy"

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation