haeknp3nnr Posted June 30, 2022 Share Posted 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 Quote Link to comment
Revan335 Posted July 2, 2022 Share Posted 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? Quote Link to comment
mgutt Posted July 2, 2022 Share Posted July 2, 2022 Du könntest so suchen was auf den Pfad zugreift: lsof | grep /mnt/cache-nvme Quote Link to comment
haeknp3nnr Posted July 3, 2022 Author Share Posted 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: Quote Link to comment
mgutt Posted July 3, 2022 Share Posted 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. Quote Link to comment
haeknp3nnr Posted July 3, 2022 Author Share Posted 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. Quote Link to comment
mgutt Posted July 12, 2022 Share Posted 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? Quote Link to comment
haeknp3nnr Posted July 24, 2022 Author Share Posted 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 Quote Link to comment
haeknp3nnr Posted August 1, 2022 Author Share Posted August 1, 2022 Mahlzeit ! Es ist nun doch mal wieder soweit .... 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 ? Quote Link to comment
hawihoney Posted August 1, 2022 Share Posted 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. 1 Quote Link to comment
mgutt Posted August 4, 2022 Share Posted 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? Quote Link to comment
haeknp3nnr Posted August 29, 2022 Author Share Posted 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. Quote Link to comment
Gorosch Posted August 29, 2022 Share Posted August 29, 2022 Hast du schon mal die Verbindung zwischen deinem PC und Unraid überprüft, ob die durchgehend sauber arbeitet? Quote Link to comment
hawihoney Posted August 29, 2022 Share Posted August 29, 2022 (edited) 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 Quote Link to comment
haeknp3nnr Posted August 29, 2022 Author Share Posted August 29, 2022 Die Netzwerkverbindung ist´s nicht. Gleiches Verhalten per LWL & Mgmt-LAN ... keine Paketverluste. Alle anderen Dienste arbeiten sauber. Quote Link to comment
hawihoney Posted August 29, 2022 Share Posted August 29, 2022 (edited) 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 1 Quote Link to comment
haeknp3nnr Posted August 29, 2022 Author Share Posted 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 ? Quote Link to comment
hawihoney Posted August 29, 2022 Share Posted August 29, 2022 (edited) 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. Edited August 29, 2022 by hawihoney Quote Link to comment
haeknp3nnr Posted August 30, 2022 Author Share Posted 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. Quote Link to comment
hawihoney Posted August 30, 2022 Share Posted 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? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.