MX Linux langer shutdown mit gemountetem Raspberry Pi

Hallo alle zusammen,

ich habe mit MX Linux das Problem, dass der shutdown des Systems mit einem per fstab gemounteten Raspberry Pi über 2 Minuten dauert.

Das ist der Eintrag in der fstab:

//IP-Adresse/Freigabe /home/roberto/Mountpunkt cifs defaults,credentials=/home/roberto/.smbcredentials,rw,nounix,iocharset=utf8,vers=3.0,uid=roberto,gid=roberto 0 0

Wenn ich den Raspberry vorher per umount manuell aushänge, fährt das System innerhalb von Sekunden runter.

Wenn ich den Raspberry über Thunar manuell einhänge, fährt das System ebenfalls innerhalb von Sekunden runter.

smb://raspberrypi.local/daten

Kann es sein, dass das Netzwerk vor der Freigabe down ist und dass deshalb diese Verzögerung auftritt?

Verwende ich den exakt gleichen fstab Eintrag in Artix, tritt diese Verzögerung nicht auf.

Hat jemand eine Idee was bei MX Linux anders ist als bei Artix und wie ich dieses Problem beheben kann, ohne jedesmal einen manuellen umount vorzunehmen?

Viele Grüße
Roberto

Ich habe zwischenzeitlich heraus gefunden, dass MX Linux trotz des Eintrages in der fstab schnell runter fährt, wenn das Notebook per LAN verbunden ist.
Nur im WLAN braucht der shutdown mehrere Minuten.

Leider hat mich das bei der Lösung des Problems auch nicht weiter gebracht :face_with_raised_eyebrow:

Ich muss mal vorwegschicken, ich bin ein absoluter Gegner von WLan incl BT-Mist.

Ansonsten:
Deine Wohnsituation, wieviele Wlans funken?
Der ort deiner Station
2.4G ? 5GHz mal getestet?
Probleme nur bein shutdown? Oder nur zu bestimmten Zeiten?
Du weisst 2.4GHz hat 13 Kanaele in D mit 5 Kanalabstand wird es eng…

Ansonsten sage ich immer: Nimm es als Hinweis und folge dem Kabel

GW

Es sind schon einige Router in meiner Nähe.

Es spielt keine Rolle, ob es 2.4 oder 5 GHz ist, ich habe beide Frequenzen getestet, kein Unterschied.

Ich kann mir nicht vorstellen, dass es am Funknetz liegt, denn ich habe auf ein und dem selben Notebook abwechselnd eine frische Installation MX Linux und danach eine frische Artix Installation getestet. Damit meine ich keine virtuelle Installation sondern eine reale auf einer SSD.

Es ist ein Thinkpad X220 und mit Artix klappt der shutdown zügig und problemlos, mit MX nicht.

Wenn ich die Freigabe vor dem shutdown manuell aushänge, dann fährt das System innerhalb von ein paar Sekunden runter.

sudo umount ~/Daten

Ich hatte dieses Problem vor 3 Jahren schon mal im MX Linux Forum, mit folgender Meldung beim shutdown pepostet:

Stopping enhanced syslogd: rsyslogd [ 1757.153231]CIFS VFS: Server (ip-adress) has not responded in 120 seconds. Reconnecting...

Dieses Problem wurde nie gelöst.

Gruß
Roberto

Man koennte fast annehmen, das dein WLan vorher schon weg ist.

Haste mal probiert, haengt von deinem DM ab, mit logout (muesstest mal schauen, nutze lightdm und beende darueber ein Programm) auszuhaengen?

Das habe ich auch schon vermutet.
MX nutzt auch lightdm, ich habe bis jetzt leider keine Idee, wie ich die lightdm.conf anpassen muss.

Hast du eine Idee?

Viele Grüße
Roberto

[Seat:*]
.
.
.
.
.
greeter-setup-script=/etc/lightdm/clevo-on.sh
greeter-cleanup-script=/etc/lightdm/clevo-off.sh

  1. wenn du dich einloggen willst
  2. wennde raus willst

es kann vllt auch sein, das anstelle von*.sh du einfach nur deinen umount befehl hinterlegst, musstest testen

GW

Ich habe ein wenig getestet u. a. auch mit einem angelegten shell Script, aber bisher leider erfolglos.
Ich bin mir aber auch nicht sicher, ob das Script richtig ist, von daher hier mal, was ich gemacht habe.

Ich habe eine .sh datei angelegt:

sudo nano /etc/lightdm/umount.sh

Dann habe ich folgendes rein geschrieben:

#!/bin/bash

umount /home/roberto/Daten

Daten ist mein Mountpunkt.

Danach habe ich per

sudo chmod +x /etc/lightdm/umount.sh

die Datei ausführbar gemacht.

Zuletzt habe ich in die lightdm.conf die Zeile

greeter-cleanup-script=/etc/lightdm/umount.sh

angepast.

Vielleicht ist meine Datei doch nicht dafür geeignet.

Hallo Roberto,
die Idee klingt schon mal gut. Kontrolliere nochmal genau die Rechte von /etc/lightdm/umount.sh, müsste mindestens root gehören und ausführbar sein. Sollte also so aussehen:

-rwxr-xr-x 1 root root 91 2021-06-09 18:11 /etc/lightdm/umount.sh

Und zur Kontrolle, füge mal nach
umount /home/roberto/Daten
noch diese Zeile ein:

echo "EXIT $?" > /home/roberto/ergebnis

und poste dann, was in der Datei steht. Der Name von /home/roberto/ergebnis ist egal, sollte nur eine Datei sein, die noch nicht existiert und die Du dir anschliessend
ansehen kannst.

viele Grüße gosia

Hallo goisa,

die Rechte meines Scripts sehen so aus:

-rwxr-xr-x 1 root root 39 Jun  9 16:39 umount.sh

Das Ergebnis in der Datei ergebnis lautet:

 EXIT 0

Ich habe mein Script zwischenzeitlich nach /usr/local/sbin verschoben, weil ich gelesen habe, dass das der Ort für systemweite bash Dateien mit root Rechten sein soll.

Der shutdown dauert nach wie vor ewig.

Viele Grüße
Roberto

Hallo Roberto,

0 als exit-Wert bedeutet eigentlich, dass der Befehl ohne Fehler durchgeführt wurde, also in deinem Fall das aushängen funktioniert hat.
Warum es trotzdem noch hängt kann ich nicht beurteilen, müsste man untersuchen.

Wenn es dort liegt musst Du aber auch dafür sorgen, dass es rechtzeitig gestartet wird. Insofern sehe ich da keinen Unterschied.
IMHO liegt das Problem tatsächlich darin, dass WLAN schon vor dem umount abgeschaltet ist und dadurch dein Samba-LW nicht mehr erreicht wird. Die einfachste Lösung wäre also das Ding ans Kabel zu hängen.
Aber normalerweise kann man auch das Aushängen vor das Abschalten schieben, indem man einen passenden Softlink in das entsprechende Runlevel legt, z.B.

sudo ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K15umountnfs.sh 
sudo ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K15umountnfs.sh

da umountnfs.sh das zuständige Skript für das umount ist. Habe ich aber noch nicht getestet.

viele Grüße gosia

Schon mal in

/var/log/lightdm/

oder in der
$HOME/.xsession-errors

geschnueffelt?

Irgendwo muss doch was zu finden sein.

Was noch nicht im focus lag ist ja smb

Hat es einen besonderen Grund dasde smb anstelle NFS gewaehlt hast?

Miir gehen die Ideen aus, nutze selbst nur nfs und ne alte NAS-Box und habe auch kein MX zum testen…

Hast auch mal in deinem Wlan-Router mal im Hinblick auf Wlan geschnueffelt? Vllt findeet sich dort ja nen Ansatz?

GW

Hallo goisa,

muss ich diese verlinkten Dateien noch anpassen?
Das ist für mich Neuland und nur diese Softlinks anzulegen hat keinen Effekt.

Klar wäre Kabel besser, aber leider komme ich nicht überall mit LAN klar.

Viele Grüße
Roberto

Hallo GypsyWolve,

ich konnte in der /var/log/lightdm nichts entdecken, habe sie aber einfach mal angehängt

[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log [+0.00s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=2502 [+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/01_debian.conf [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/02_MX.conf [+0.00s] DEBUG: [SeatDefaults] is now called [Seat:*], please update this configuration [+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf [+0.00s] DEBUG: [Seat:*] contains unknown option greeter-cleanup-script [+0.00s] DEBUG: Registered seat module local [+0.00s] DEBUG: Registered seat module xremote [+0.00s] DEBUG: Registered seat module unity [+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager [+0.15s] DEBUG: Monitoring logind for seats [+0.15s] DEBUG: New seat added from logind: seat0 [+0.15s] DEBUG: Seat seat0: Loading properties from config section Seat:* [+0.15s] DEBUG: Seat seat0: Starting [+0.15s] DEBUG: Seat seat0: Creating greeter session [+0.15s] DEBUG: Seat seat0: Creating display server of type x [+0.15s] DEBUG: posix_spawn avoided (fd close requested) [+0.15s] DEBUG: posix_spawn avoided (fd close requested) [+0.15s] DEBUG: Seat seat0: Plymouth is running on VT 1, but this is less than the configured minimum of 7 so not replacing it [+0.15s] DEBUG: Quitting Plymouth [+0.15s] DEBUG: posix_spawn avoided (fd close requested) [+0.23s] DEBUG: Using VT 7 [+0.23s] DEBUG: Seat seat0: Starting local X display on VT 7 [+0.23s] DEBUG: XServer 0: Logging to /var/log/lightdm/x-0.log [+0.23s] DEBUG: XServer 0: Writing X server authority to /var/run/lightdm/root/:0 [+0.23s] DEBUG: XServer 0: Launching X Server [+0.23s] DEBUG: Launching process 2637: /bin/X -dpi $DPI :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 [+0.23s] DEBUG: XServer 0: Waiting for ready signal from X server :0 [+0.23s] DEBUG: Acquired bus name org.freedesktop.DisplayManager [+0.24s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0 [+0.28s] DEBUG: Loading users from org.freedesktop.Accounts [+0.28s] DEBUG: User /org/freedesktop/Accounts/User1000 added [+0.32s] DEBUG: posix_spawn avoided (automatic reaping requested) (fd close requested) [+1.37s] DEBUG: Got signal 10 from process 2637 [+1.37s] DEBUG: XServer 0: Got signal from X server :0 [+1.37s] DEBUG: XServer 0: Connecting to XServer :0 [+1.42s] DEBUG: Launching process 2831: /usr/local/bin/early-bg [+1.43s] DEBUG: Process 2831 exited with return value 0 [+1.43s] DEBUG: Seat seat0: Exit status of /usr/local/bin/early-bg: 0 [+1.43s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified) [+1.43s] DEBUG: Seat seat0: Display server ready, starting session authentication [+1.43s] DEBUG: Session pid=2837: Started with service 'lightdm-greeter', username 'lightdm' [+1.45s] DEBUG: Session pid=2837: Authentication complete with return value 0: Success [+1.45s] DEBUG: Seat seat0: Session authenticated, running command [+1.45s] DEBUG: Launching process 2840: /usr/bin/lightdm-shutdown [+1.47s] DEBUG: Process 2840 exited with return value 0 [+1.47s] DEBUG: Seat seat0: Exit status of /usr/bin/lightdm-shutdown: 0 [+1.47s] DEBUG: Session pid=2837: Running command /sbin/lightdm-gtk-greeter [+1.47s] DEBUG: Creating shared data directory /var/lib/lightdm/data/lightdm [+1.47s] DEBUG: Session pid=2837: Logging to /var/log/lightdm/seat0-greeter.log [+1.49s] DEBUG: Activating VT 7 [+1.49s] DEBUG: Activating login1 session c1 [+1.50s] DEBUG: Seat seat0 changes active session to c1 [+1.50s] DEBUG: Session c1 is already active [+1.73s] DEBUG: Greeter connected version=1.26.0 api=1 resettable=false [+2.17s] DEBUG: Greeter start authentication for roberto [+2.17s] DEBUG: Session pid=2956: Started with service 'lightdm', username 'roberto' [+2.18s] DEBUG: Session pid=2956: Got 1 message(s) from PAM [+2.18s] DEBUG: Prompt greeter with 1 message(s) [+7.83s] DEBUG: Continue authentication [+7.85s] DEBUG: Session pid=2956: Authentication complete with return value 0: Success [+7.85s] DEBUG: Authenticate result for user roberto: Success [+7.85s] DEBUG: User roberto authorized [+7.87s] DEBUG: Greeter sets language de_DE.utf8 [+7.89s] DEBUG: Greeter requests session lightdm-xsession [+7.89s] DEBUG: Seat seat0: Stopping greeter; display server will be re-used for user session [+7.89s] DEBUG: Terminating login1 session c1 [+7.90s] DEBUG: Session pid=2837: Sending SIGTERM [+7.91s] DEBUG: Greeter closed communication channel [+7.91s] DEBUG: Session pid=2837: Exited with return value 0 [+7.91s] DEBUG: Seat seat0: Session stopped [+7.91s] DEBUG: Seat seat0: Greeter stopped, running session [+7.91s] DEBUG: Launching process 3455: /usr/bin/lightdm-at-spi-fix [+7.92s] DEBUG: Process 3455 exited with return value 0 [+7.92s] DEBUG: Seat seat0: Exit status of /usr/bin/lightdm-at-spi-fix: 0 [+7.92s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0 [+7.92s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified) [+7.92s] DEBUG: Session pid=2956: Running command /etc/X11/Xsession default [+7.92s] DEBUG: Creating shared data directory /var/lib/lightdm/data/roberto [+7.92s] DEBUG: Session pid=2956: Logging to .xsession-errors [+7.97s] DEBUG: Activating VT 7 [+7.97s] DEBUG: Activating login1 session 1 [+7.97s] DEBUG: Seat seat0 changes active session to 1 [+7.97s] DEBUG: Session 1 is already active

Ansoonsten habe ich es auch mit NFS in der fstab versucht, leider ebenfalls ohne Erfolg.

IP-Adresse:/Freigabe /home/roberto/Mountpoint nfs rw 0 0

Ich habe noch nicht heraus gefunden, wieso es bei einem Arch basierten Linux klappt und bei einem Debian basierten Linux nicht.

Viele Grüße
Roberto

Hallo Roberto,

Nein, lass die Finger davon.
Naja, man kann die init-Skripte natürlich anpassen, wenn man weiss, was man macht. Aber notwendig ist es nicht und ich selbst würde die Finger davon lassen.
Eine Anpassung wäre beim Namen der verlinkten Datei, oder besser gesagt bei der Nummer hilfreich, also z.B. statt K15umountnfs.sh → K01umountnfs.sh
Der Witz dabei ist nämlich, dass die in alphabetischer Reihenfolge abgearbeitet werden (aber das K bei /etc/rc6.d/K15umountnfs.sh muss bleiben, das ist eine Abkürzung dafür, dass der betreffende Init-Prozess gestoppt werden soll).
Aber ehrlich gesagt bin ich von der lightdm-Idee fasziniert und möchte verstehen, warum die nicht funktioniert. Wenn Du möchtest, bastle ich noch ein wenig Code für das Skript, aber heute wird es nix mehr. Und auch nur, wenn Du nichts dagegen hast.
Ansonsten habe ich noch so ein bis zwei Ideen in der Hinterhand, die müssen aber erstmal reifen…

viele Grüße gosia

Hallo gosia,

nein, ich habe absolut nichts dagegen, ganz im Gegenteil :slight_smile:

Es eilt auch nicht, also mach einfach so, wie es dir passt. Ich freu mich doch, dass du dich meines Problems annimmst.
Ich frage mich schon die ganze Zeit, ob evtl. lighdm und/oder sysVinit daran schuld sein kann.
Definitiv funktioniert es mit sddm und/oder openrc.

Da bin ich mal gespannt … :slight_smile:

Viele Grüße
Roberto

Hallo Roberto,

Na das ist ja mal eine Überraschung… Habe ich das irgendwo überlesen oder ist das tatsächlich eine neue Info?
Da liegt nun die Frage nahe, sddm und/oder openrc magst Du nicht??? Wäre ja eine Möglichkeit. Aber einen Einfluss von sddm auf das Problem kann ich mir nicht so recht vorstellen. Welcher Init-Prozess spielt ganz sicher eine Rolle, denn Init-Prozesse fahren ja bei Bedarf die Prozesse (und damit auch die WLAN-Verbindung) auch wieder runter.

viele Grüße gosia

Hi gosia,

nein, das ist insofern keine neue Info, als das ich schon öfter schrieb, dass ich mit Artix diese Probleme nicht habe.
Was ich aber tatsächlich nicht explizit erwähnt habe, dass es Artix OpenRC, KDE Plasma 5 mit sddm als Displaymanager ist. Deswegen verstehe ich natürlich deine Verwirrung bzw. Überraschung.

Ich spiele also mit dem Gedanken bei Artix zu bleiben, obwohl ich MX immer besser finde.

Viele Grüße
Roberto

Ich setze mal voraus, das du wohl irgendeine NAS software einsetzt

Bisher wurde ja nur MX ins Visier genommen, aber was ist wennNAS ein Kommunikationsproblem mit MX hat?

Als absoluter Geger von wifi, folge dem Kabel…

GW

Da nimmst du völlig richtig an, ich setze Openmediavault als NAS Software ein.
Ausgeschlossen ist es nicht, dass dort ein Kommunikationsproblem herrscht.
Das heraus zu finden wird schwierig.
Ich würde auch gerne dem Kabel folgen, aber im Wohnzimmer ist das leider nicht so einfach.