Shutdown + SMB-Shares in Debian 9

[Schreibtroll]

Moin zusammen!

Ich habe mir mal wieder Debian (9) installiert. Läuft auch alles astrein sauber bis auf eines:

Ich habe Samba-Shares gemountet. Platte an der Fritz und eine NAS.

→ Fahre ich die NAS runter bevor ich die Shares dismountet habe, dann hängt sich der Caja-Daemon (Mate) auf.

→ Fahre ich Debian runter, dann dauert es ca. 1 Min bis sich Mate verabschiedet und weitere 5 Min bis die Kiste aus ist.

Kommentiere ich die Shares in der fstab aus, fährt die Kiste ratzfatz runter.

Wo kann man drehen, um dieses Verhalten abzustellen? Ich erinnere mich, dass das früher in Ubuntu/Mint auch so war (bis 2012??). Meine Vermutung geht dahin, dass erst das Netzwerk gekappt wird und dann 5 Min versucht wird, die Shares auszuhängen.

[Schreibtroll]

Äh - whats wrong??

Fehlt was? Hab ich die Urlaubszeit erwischt? Hab ich "Euch" auf dem falschen Dampfer erwischt??

Wenns Fehlermeldungen in den Logs gäbe, dann hätt ich was zum Googlen. Aber da es normale Routinejobs sind, ist halt nix da. Oder versteckt und ich habs nicht gefunden...Leider gibts ja in Debian keine rotierenden dmesg, die mir aber auch nix bringen würden, weil ich da dann nur ein Zeitloch sehe.

[marce]

Wie sehen denn die mount-optionen aus?

Du nutzt schon systemd? Evtl. kannst Du darüber ja was herausfinden... journalctl kann ja so einiges...

[Schreibtroll]

ja marce - ich denke, bei Testing läuft schon systemd.

Stellvertretend für alle shares:


//192.168.178.26/freigabe/ /home/schleppi/WEB cifs uid=1000,gid=46,credentials=/home/schleppi/auth.192.168.178.26 0 0

in der auth steht nur:



user=ichdoch
password=ganzgeheim


wie es seit 2012 auch für Fritz.Box sein muss für cifs. Soweit funzt ja auch alles prima. Nur das Runterfahren ist öde wenn man bis zu 6 Min warten muss. Ich weiss nicht, was Mark (Ubu) oder Clem (Mint) da geändert haben. Ob sie die shares einfach "abschiessen"? Die sind ja eh nicht mehr da wenn Netzwerk runtergefahren ist. In Mint_17 (Qiana) jedenfalls habe ich das nicht - fährt ratzfatz runter.

Wenn dem so wäre (oder auch nicht) - wo könnte man das wie eintragen?

[marce]

Grundlegend gibt's da immer viele Möglichkeiten:
- Sind noch Locks auf dem Share (also z.B. offene Dateien?)
- umount wird nach network-stop gemacht (AFAIK jedenfalls, ggf. auch deswegen Netwerkmount nicht in die fstab sondern z.B. als ded. Service)
- ggf. Mountoptionen wie bg, soft, timeo, ... setzen (Doku zu mount.cifs dürfte hilfreich sein), ggf. mal auch die defaults von alt und neu vergleichen oder ggf. über die Samba-Version drüber schauen, ...
- Tools wie automount verwenden, die dynamischer sind als die fstab-Methode
- "Check'n'kill"-Scripte drumrum basteln
- mal schauen, ob journalctl auch ein blame für den shutdown bietet.
- ...

Mal sehen, was mein Hirn noch so ausspuckt - später aber erst.

[firemanho]

Habe ebenfalls ein derartiges Problem bei meinem Arch system. Jedoch nur im WLAN. Mit Kabel klappt das runterfahren

[Schreibtroll]

Nene - an sowas habe ich ja gar nicht gedacht. :D

Natürlich ists hier auch WLan - an die Leine kommt mein Notie nur zur Installation weil etwas kompliziert hier. Also ists wohl doch die Variante, die ich vermute.

[firemanho]

Also liegt es daran, dass die Verbindung abgebrochen wird bevor die Laufwerke ausgegangen werden. Ich hänge die Laufwerke allerdings über den Networkmanager (preup und predown Skript) ein und aus. Eigentlich sollte damit ja alles funktionieren. Tut es aber nicht. Bei mir hilft evtl. das predown Skript zu löschen. Aber das wäre auch nur Pfusch.

[Schreibtroll]

Ich löse das derzeit auch mit "umount". Ist aber öde, dafür dann Ruth zu wecken.

So etwas muss doch auch eleganter gehen.

[Mäuseturm]

Ich kenne das Problem nur zu gut, habe mich damit wochenlang herum geärgert und zu lösen versucht, aber ohne Erfolg. Da mir auch in keinem Forum geholfen werden konnte, habe ich dann irgendwann gefrustet Arch vom Notebook verbannt.

Der Übeltäter ist dieser systemd-Schrott. Das ist auf dem Notebook mit WLAN reproduzierbar (auch nach mehreren Neuinstallationen), ist kurioserweise aber auch schon auf meinem per Netzwerkkabel angebundenen PC passiert: die Netzwerkverbindung scheint wohl gekappt zu werden, bevor die CIFS-/Samba-/NFS-Mounts ausgehängt werden und dann bleibt systemd beim Herunterfahren erst mal stehen und zählt immer genau 1:30 Minute herunter, bevor es dann (hoffentlich) wirklich fertig herunter fährt. Ich hatte es aber auch schon, dass er diese 1:30 Minute Prozedur für jeden mount durchgezogen hat. Gerne auch beim Hochfahren, wenn NFS-Mounts in der fstab stehen.

Ich habe mich dann auch noch sehr lange damit beschäftigt, irgendwie automatisiert über die Möglichkeiten vom networkmanager oder systemd selbst die Mounts vor dem Beenden der Netzwerkverbindung aushängen zu lassen. Aber auch das ist mir nicht gelungen. Ich bin immer nur über mehr und mehr Murks in systemd und networkmanager gestolpert. Und irgendwann war es mir dann einfach zu blöd. Dieser Krampf ließ sich bei mir nur umgehen, in dem ich vor dem Herunterfahren über die Shell alle mounts per Hand ausgehängt habe.

Das ist beileibe nicht der einzige Grund, warum ich längst eine ausgesprochen tiefe Abneigung gegen systemd entwickelt habe. Aber es ist der Hauptgrund, warum für mich nach über 15 Jahren Debian auf dem Desktop gestorben ist... ;)

Mein Tipp: nimm das alte Debian Wheezy oder Linux Mint (Debian Edition). Wheezy war noch ganz ohne systemd, Mint soll sich dem wohl derzeit auch noch verweigern. Jedenfalls wirst Du dieses Problem mit beiden nicht haben.

[firemanho]

Ich werde mich in nächster Zeit wohl mal wieder mit dem Thema beschäftigen und nach einer Lösung suchen da ich mich nicht von meinem Arch trennen möchte. Bisher war die Lösung halt Patchkabel drin lassen. Ist aber schon doof bei einem Notebook.

[Schreibtroll]

@ Mäusesturm: Spätestens, wenn Wheezy "stirbt" und man es hochheben muss, hat man dann die gleichen Probleme wie jetzt.

***

Momentan habe ich noch die Mint_17-Mate parallel. Da passiert das ja nicht. Aber früher gab es dieses Verhalten ja auch schon mal. Ich weiss jetzt nicht, was Marc oder Clem da gefummelt haben - evtl. "Shares bei WLan nicht abmelden sondern abschiessen" ??

Systemd wird eh kommen. Und die Frage ist, wie lange Ubu/Mint noch nutzbar ist. Welche Auswirkungen Snappy da haben wird, lässt sich ja noch gar nicht absehen. So wie es sich derzeit liest, ist das für mich dann der Ausstieg aus allem wo Ubu hintersteht - also auch Mint.

Das Problem ist ja, dass nix protokolliert wird, weil das Script ja genau das macht, was es soll - bei mir sinds 4 Shares also 4 x 1,5 Min. Klasse.

Irgendwie müsste also für Shutdown/Poweroff als allererster Befehl ein umount rein. Oder aber wie oben: Falls WLan: Shares abschiessen. Das kann ich nicht umsetzen.

[BetterWorld]

Unter systemd braucht man keine Einträge für CIFS shares.
Es genügt eine mount.unit/service dafür.

Das kann man trotzdem als Bug sehen, der auch bei Freedesktop.org im Bugtracker (http://cgit.freedesktop.org/systemd/systemd/commit/?id=77009452cfd25) zu finden ist.

Es sollte aber genügen, die Einträge für CIFS und NFS mounts in der /etc/fstab zu löschen, und statt dessen für die jeweiligen Mounts eine eigene Mountunit zu schreiben.
Da ich radikal Win-freie Zone bin und auch kein Netzwerk mit mehreren Maschinen habe (auf unseren Server kommt sowas nicht, und es läuft dort natürlich Wheezy), kann ich leider nicht viel weiter helfen.

Ein man 5 systemd.mount hilft.
Im Prinzip werden aus /etc/fstab Einträgen beim Start durch einen systemd-generator solche fstab-Zeilen in systemd- Sprech übersetzt.
Sind für solche Shares unit/service files definiert, so haben die sogar Vorrang vor den fstab-Einträgen.

Das Erstellen von mount und umount unti/service files sollte das also lösen.
Ich denke, man kann aber auch einfach warten, da das -wie ich meine- "gefixt" wird.