Failed umounting /home

[fixedwater]

Hallo zusammen,

auf meinem Hauptrechner mit Ubuntu Budgie 18.04 erhalte ich seit einiger Zeit beim shutdown immer mal wieder die Fehlermeldung "failed umounting/home" (rot markiert). Das System fährt dennoch problemlos runter. Der Fehler ist für mich nicht reproduzierbar, taucht auch nicht immer auf - beim Start gibt es nie Fehlermeldungen. Ein paar Hardwareinfos: Ist ein i5-4570 mit 16 GB DDR3, es gibt zwei 1 TB-Platten von WD (WD Green mit mount-Punkt /home und eine weitere WD mit mount-Punkt /backup), System liegt auf einer Samsung-SSD mit 128 GB. System arbeitet mit Kernel 4.15.0-47-generic und ist ansonsten superstabil.
Leider bin ich beim googlen nicht wirklich schlauer geworden. Kann jemand etwas dazu sagen?
Vielen Dank!

 

[snaxilian]

Betreibst du irgendwelche Dienste wie NFS oder Samba, die /home oder etwas darin frei geben? Was sagen syslog/dmesg/kern.log bzw journald von systemd? Da muss ja ein Hinweis während des Shutdowns zu finden sein wenn der Fehler auftrat.

 

[sky^xs]

Könnte mir vorstellen, dass noch irgendein Prozess läuft, der auf /home zugreift und dementsprechend das Unmounten verhindert, da noch in use.
Geht die Fehlermeldung so in diese Richtung: "umount: /home device is busy (which processes use this device can be possibly be found with lsof or fuser)"?

Dann wäre es evtl. interessant vor dem Shutdown mal
"lsof /home" -> listet offene Files in /home
"fuser -mv /home" -> alle Prozesse anzeigen, die aktuell auf /home zugreifen

Und natürlich die Frage, die snaxilian gestellt hast. Das war auch mein erster Gedanke, da ich mit meinem Linux Server auf Windows Shares zugreifen, die gelegentlich rumzicken. Aber das /home von einem Windows System zu mounten fände ich ungewöhnlich...

 

[fixedwater]

Danke schon mal. Ja, es gibt in /home ein Verzeichnis, in das ich über nfs meine Verzeichnisse von meinem NAS mounte. Eine Meldung wie "device is busy" gibt es beim Runterfahren aber nicht. Wie könnten man denn überprüfen, ob das NAS-Verzeichnis die Ursache des Problem ist?

 

[snaxilian]

DAS ist die Ursache. Dein System "verhaspelt" sich und versucht bereits /home auszuwerfen aber zu dem Zeitpunkt sind die NFS-Freigaben noch gemountet.

Lösungsvorschlag: Bastel dir ein pre-shutdown-Skript, was die NFS-Shares sauber entfernt, z.B. als systemd unit mit Abhängigkeit zum Netzwerkinterface.

 

[fixedwater]

Hm, das mit dem Skript erscheint logisch - aber dafür fehlt mir leider das Know-How Ich versteh das jetzt mal so: Ich bastele mir ein Skript, dass dann die Befehle zum umounten der NAS-Freigaben ausführt, diesen Befehl könnte ich mir dann irgendwo ins Menu einbauen oder im Terminal ausführen? Gibts da ne Anleitung, die Du mir empfehlen könntest?

Edit: Bin ich hier eventuell schon richtig?
https://www.linuxquestions.org/ques...systems-without-unmounting-local-ones-709400/

Nächster Edit: der Befehl umount -a -t nfs funktioniert... fragt sich nur noch, wie man das möglichst komfortabel umsetzt.

Ergänzung (9. April 2019)

Ah, sorry - und noch eine Frage (dann gehts ins Bett ): Könnte man auch an den Mountoptionen in /etc/fstab was drehen, um das wegzubekommen? Bisher laufen die Laufwerke mit auto,users,rw,suid,dev,exec,async rein...

 

[sky^xs]

In der fstab kannst du etliche Parameter setzen. Ich habe damit bei mir lange "rumprobiert" und alles ausprobiert, allerdings ohne signifikanten Unterschied. Meistens funktionierte es genau einmal und beim nächsten Shutdown hing es wieder beim unmounten.

Nachdem ich mich dann ein wenig googlenderweise damit befasst habe, habe ich auf einen Tip hin ein neues Script in etc/init.d angelegt (s.u. umount_all.sh) und in /etc/rc6.d (dem Shutdown Runlevel) als Link angelegt. Dort liegen die Scripte, die zum Shutdown ausgeführt werden.

Das Script selbst ist relativ einfach gehalten:

filename: /etc/init.d/umount_all.sh

#!/bin/bash

# Must be run as root
echo "*** Unmount all shares prior to shutdown ***"
echo `date +"%Y-%m-%d - %H:%M"`

umount -lf /media/e
umount -lf /media/f
...

Das Skript machst du dann ausführbar mit

chmod 755 /etc/init.d/umount_all.sh

Das Script wird dann nach /etc/rc6.d (dem Shutdown Runlevel) verlinkt.
Der Befehl dazu sollte etwa so aussehen:

ln -s /etc/init.d/umount_all.sh /etc/rc6.d/K01umount_all.sh

und sieht dort dann so aus

lrwxrwxrwx   1 root root    23 May 14  2018 K01umount_all.sh -> ../init.d/umount_all.sh

Das K01 signalisiert, dass es relativ am Anfang des Shutdowns abgefahren wird. K00 wäre direkt am Anfang. Du kannst ja mal in das rc6.d Verzeichnis gehen und schauen, was da sonst so an Skripten liegt und wann die abgefahren werden (K0x) etc...

Prüf die Syntax bitte vor "produktiv Schaltung" mal. Das ist jetzt quasi abgetippt vom anderen Schirm. Kommentare usw. willkommen. Bei mir war das die Lösung, die den Shutdown bisher immer durchlaufen ließ. Früher hing immer mal das eine oder andere Share - da hängen ca. 10 oder so dran

 

[fixedwater]

Joa, bei mir sinds fünf.... Komplettes Neuland für mich. Ich gucke mir das heute Abend Mal an. Danke schon mal!

 

[fixedwater]

Eieieieiei... hab mal ein wenig rumprobiert, aber bin nicht wirklich weitergekommen... mir fehlen da wohl etwas die Grundlagen und derzeit auch die Zeit. Hab mir umount -a -t nfs jetzt erst einmal als Tastenkombi definiert, die man immer vor dem shutdown kurz mal ausführen kann...

 

[sky^xs]

Woran hapert's? Frag ruhig.
Du musst natürlich Ruth sein, um die Befehle ausführen bzw. um die Datei anlegen zu können, etc. aber damit erzähle ich dir vermutlich nix neues . Das ist alles keine rocket science. Wenn ich das Skript oder die Befehle erklären soll, einfach kurz fragen..

 

[fixedwater]

Danke fürs Angebot. Ich hab mit Scripten halt noch nie auch nur ansatzweise gearbeitet und mit den Runlevels auch so gar nicht
Hatte aber nun noch eine andere Idee: Da meine Tochter (5) sich in letzter Zeit angewöhnt hat, aus Spaß den PC über den Runterfahrbutton der Budgie-Leiste runterzufahren (sie kennt das Symbol, argl!!), obwohl noch wichtige Sachen offen sind, hatte ich mir überlegt diese Funktion mit root-Passwort zu schützen. Ich habe nun in Plank einen Knopf abgelegt, hinter dem der Befehl sudo umount -a -t nfs hinterlegt ist. Drückt man da drauf, öffnet sich ein Terminalfenster, man gibt das root-Passwort ein und der Befehl wird ausgeführt. Nun könnte ich ja auch folgende Syntax hinterlegen:

sudo umount -a -t nfs; shutdown -h now

Frage dazu: Wenn man diese beiden Kommandos mit ; trennt - wird dann zuerst das erste und DANACH das zweite abgearbeitet? Oder lieg ich da völlig falsch?
Thx!

 

[snaxilian]

Mache es so:sudo umount -a -t nfs && shutdown -h now
Trennst du es per ; dann werden die Befehle unmittelbar hintereinander ausgeführt. Bei && wird zuerst der erste Teil ausgeführt und wenn der erfolgreich ist der zweite Teil. Quelle: https://wiki.ubuntuusers.de/Shell/Operatoren/

 

[fixedwater]

Jawollja, vielsten Dank - funktioniert und System fährt nun auch gefühlt 3x so schnell runter Richtung Sommer will ich dann eh das System umbauen, mal sehn, ob das dann noch auftaucht...

 

[lokked]

Also mit modernen Linux Systemen, die mit systemd laufen (fast alle aktuellen Mainstream Distros), kann man sich den Aufwand von custom Skripten sparen, indem man die fstab anpasst.

noauto,x-systemd.automount,x-systemd.device-timeout=30,_netdev

in der /etc/fstab als zusätzliche Mountoptionen bei Netzwerkfreigaben eintragen (timeout kann man weglassen).

Hat folgende Vorteile:

• Das System startet schneller, da das Netzwerk noch nicht up sein muss wenn die Share gemountet wird (NFS4)
• Es wird nur gemountet wenn man drauf zugreift, d.h. sie auch braucht
• Beim Runterfahren gilt die umgekehrte Reihenfolge wie beim Start der Dienste, was bedeutet das die Netzwerkshares prinzipiell immer vor den physischen Dateisystemen bzw. Mountpunkten ausgeklinkt werden, da man ja später auf sie zugegriffen hat. Wenn nicht, dann halt auch kein umount erforderlich. -> Wiederum schnelleres Runterfahren.

Habe hier ca 8 Netzwerkshares gemountet und eins davon ins Inet, da ist das schon deutlich bequemer so, vor allem beim Start von einer sehr schnellen NVME, wo man dann nicht auf den Netzwerkstack warten muss.
Wenn ich im Desktop bin, ist das Netzwerk gerade up bzw habe ich eine IP zugeteilt bekommen.

 

[sky^xs]

@lokked

Interessant, das werde ich mal ausprobieren.
mit "no-auto" und "automount" hatte ich auch schon experimentiert, allerdings ohne die folgenden Parameter. Dabei ging das beim ersten Neustart i.d.R. gut, beim nächsten wieder nicht mehr, daher hatte ich mir das entsprechend umgebaut und war froh, dass es läuft.
Mein Fall ist da vielleicht eh etwas anders gelagert. Ich habe einen Server 2012R2 auf dem einige Linux VMs laufen (u.a. ein Pihole und eben die VM auf der das oben gezeigte Skript läuft). D.h. die Netzwerkthematik ist da in gewisser Hinsicht ausgeklammert - virtuelle Netzwerke. Die VM kann nur laufen, wenn der Host mit den Laufwerken, auf dem die VM läuft, da ist.

 

[lokked]

@sky^xs
In dem Fall kannst du noauto und x-systemd.automount weglassen, da du das nicht brauchst bzw nichts davon hast. Sparste dir die Verzögerung beim ersten Zugriff.

_netdev sollte dann reichen, weil das bewirkt das extra Start/Stopdienste für die mounts in der fstab generiert werden, die beim Hochfahren garantiert nach dem Netzwerkdienst ausgeführt werden, und beim Runterfahren eben davor.
Physische Mounts, hier das rootfilesystem in dem dein /home Ordner liegt, kommen beim Booten normal immer vor dem Netzwerkstack (logisch). So sollte es keinen Konflikt mehr geben können.

 

[sky^xs]

So hab das mal in meiner fstab hinzugefügt und werde, wenn die VM morgen mal idlen sollte, einen Reboot fahren. Bin gespannt.

 

[sky^xs]

Habs gerade mal ausprobiert, Reboot usw. Ich merke aktuell keinen wirklichen Unterschied in der Zeit zwischen den beiden Varianten beim starten oder das es jetzt schneller läuft. Die Mounts sind alle da, also soweit alles in Butter . Da die VM aber eh auf einer SSD liegt, und die Laufwerke, wie gesagt im selben Host verbaut sind, habe ich da eh nicht den großen Unterschied erwartet. Aber es hat sich auch nix verschlechtert .

 

[fixedwater]

Ich habs auch ausprobiert - funktioniert soweit gut, Bootzeit hat sich aber gefühlt bei mir nicht wirklich verändert... Habs mal in meiner fstab vorerst auskommentiert hinterlegt Denn gestern (oder vorgestern) kam ein Update für verschiedenen nfs-Krams. Hab seitdem mal normal runtergefahren - keine Probleme mehr Wird mal beobachtet.

 

[sky^xs]

Hm,
ich hab im Moment das Problem das ein automatisierte Copy Job (via rsync) Daten von einem Share nicht mehr zum anderen Share kopiert.