[gelöst] Reboot/Shutdown Problem Debian Buster KDE

[TomL]

Hab mal zurück gekramt in den Logs, als es noch mariadb bei mir gab, und kann das nicht bestätigen.

Die Mariadb-Service-Unit enthält (s.o.) das Statement After=network.target. Das target ist nach meinem Wissen hierbei aber nur relevant für den System-Start. wpa-supplicant hingegen hat meiner Meinung nach jedoch absolut gar nichts mit dem network.target zu tun... weil via wpa-supplicant völlig unabhängig vom Systemstart oder Shutdown und auch dem network.target quasi jederzeit on-the-fly eine Verbindung auf- und abgebaut werden kann. Der TE sagt ja selber, dass erst beim Login mit GUI eine Verbindung hergestellt wird.... was in dem Fall also lange "after network.target" bedeutet. Warum das jetzt bei Dir in der richtigen Reihenfolge abläuft könnte man untersuchen, in der gegebenen Darstellung ist dazu jedenfalls nix grundsätzlich erklärendes enthalten, sondern nur die Tatsache beschrieben, dass es auch anderes sein kann.

Ich gehe sogar davon aus, dass das bei mir auch reibungslos funktionieren würde, weil ich die WLAN-Verbindung mit eigener Service-Unit selber zum Teil des Systemstarts gemacht habe. Insofern würde auch die Reihenfolge beim shutdown zu keinen Problemen führen.

Was ich jetzt hier aber eben nicht weiss, ist der Umstand, inwiefern die lokale mariadb überhaupt was mit dem Netz zu tun hat. Wenn sie nix mit dem Netz zu tun hat, weil sie vielleicht gar nicht verwendet wird, war mein Hinweis falsch. Wenn sie allerdings selber aktiv im Hintergrund darauf wartet, dass irgendwann irgendwo eine Netzverbindung hergestellt wird und wenn sie dann darauf einen Socket (vielleicht zum Login) erstellt, hat sie sehr wohl was damit zu tun. Ich kenne mariadb nicht und kann deshalb nur mutmaßen. Aber genau dann knallts eben, wenn wpa-supplicant die WLAN-Verbindung außerhalb der regulären Shutdown-Reihenfolge schließt.

Ich glaube, es wäre deshalb wirklich das einfachste, mariadb einfach mal zum Testen in Conflict mit dem shutdown.target zu setzen. Dann sieht man doch, ob es daran gelegen hat. Ich wüsste wirklich nicht, welche andere Abhängigkeit noch bestehen könnte... zumal ich davon ausgehe, dass systemd das ordentlich in umgekehrter Reihenfolge (Start zu Shutdown) sauber handhabt.

[JTH]

Die Mariadb-Service-Unit enthält (s.o.) das Statement After=network.target. Das target ist nach meinem Wissen hierbei aber nur relevant für den System-Start.

Das stimmt tatsächlich nicht. Zumindest laut man systemd.special ist network.target u.a. genau dafür gedacht das Abschalten des Netzwerks beim Shutdown erst nach netzwerkabhängigen Services einzusortieren:

network.target

[…] with one exception: at shutdown, a unit that is ordered after network.target will be stopped before the network — to whatever level it might be set up then — is shut down. It is hence useful when writing service files that require network access on shutdown, which should order themselves after this target, but not pull it in. […]

So wie das mariadb.service anscheinend ja auch macht.

[novalix]

Ich schreibe hier von einem Laptop, dessen wlan von network-manager "betreut" wird, mit KDE und mariadb auf buster.
Keine Probleme beim shutdown.
Es gibt auch noch einen Desktop-Rechner und auf Maloche eine VM mit dem Gespann buster, KDE, mariadb.
Keine Probleme beim shutdown.
Dann wäre da noch eine Datenbankserverinstanz, die bereits unter buster läuft und wenig überraschenderweise auch mariadb beinhaltet. Die wird natürlich nur selten runtergefahren, aber bei der Einrichtung und bei Kernelupdates doch das eine oder andere mal.
Keine Probleme beim shutdown.

Also aus meiner Sicht handelt es sich eher nicht um ein allgemeines Problem. Typischer corner case.

Die Vermutung mit dem network.target könnte man verfolgen. Allerdings lauscht mariadb ohne händische Konfiguration eh nur am loopback.

Die Startmeldungen von mariadb sagen über Bande durchaus etwas über den zurückliegenden shutdown aus.
Es scheint keinen Crash gegeben zu haben, da beim Neustart keinerlei Reperaturmaßnahmen durchgeführt werden, oder gar etwaige Beulen den Neustart verhindern.

Wahrscheinlich wird mariadb durchaus (zumindest zum größten Teil) ordentlich beendet, aber irgendjemand hat das in dem ganzen Gewusel nicht mitbekommen.

Warten wir erst mal ab, was nach der Anpassung der Hardware-Uhr passiert.
Ansonsten rückt als nächstes das network.target und app-armor auf die divinatorische Regentanz-Agenda.

[TomL]

Das stimmt tatsächlich nicht. Zumindest laut man systemd.special ist network.target u.a. genau dafür gedacht das Abschalten des Netzwerks beim Shutdown erst nach netzwerkabhängigen Services einzusortieren:

wpa-supplicant ist nicht direkter Bestandteil der systemd-netwerksteuerung und auch nicht Bestandteil des Systemstarts. Das ist ein tool, was von irgendwem irgendwann (üblicherweise der NWM, üblicherweise zwischen (!) Systemstart und Poweroff) zur Herstellung einer WLAN-Verbindung verwendet wird. Das ist ja gerade das symptomatische bei Mobilgeräten... mal ist eine Verbindung gegeben, mal an einem anderen Netz, mal aber auch gar nix. Für das Anziehen des netzwerk.targets ist wahrscheinlich der Start des NWM verantwortlich, aber nicht, ob mit wpa-supplicant eine Verbindung hergestellt wurde... insofern hat der Zustand von wpa-supplicant imho auch keine Bewandtnis für den Shutdown... es sei denn, man konfiguriert das ausdrücklich. Meines Erachtens reagiert wpa-supplicant selber auf ein Poweroff-Signal, durch das shutdown.target oder wodurch auch sonst.... und knallt in der Folge einfach die Verbindung weg, unabhängig davon, ob der NWM noch läuft und darauf wartet, dass er angepasst an die reguläre Reihenfolge Netzwerk und NIC schließen kann.

Das wird auch imho deutlich, wenn man sich die Unit-Section der beiden Service-Units mal anschaut... da sieht man, dass die Reihenfolge beim Shutdown zufällig sein muss... also wenn wpa-supplicant als Daemon läuft... mal wirds passen, mal nicht:

Code: Alles auswählen

# systemctl cat network-manager.service
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target 

Code: Alles auswählen

# systemctl cat wpa_supplicant.service
[Unit]
Description=WPA supplicant
Before=network.target
After=dbus.service
Wants=network.target

[MSfree]

Für das Anziehen des netzwerk.targets ist wahrscheinlich der Start des NWM verantwortlich, aber nicht, ob mit wpa-supplicant eine Verbindung hergestellt wurde... insofern hat der Zustand von wpa-supplicant imho auch keine Bewandtnis für den Shutdown...

wpa_supplicant wird entweder vom NWM oder von ifup gestartet, je nach dem, ob man NWM oder /etc/network/interfaces verwendet. Beendet wird wpa_supplicant entweder, wenn NWM beendet wird oder wenn ifdown ausgeführt wird.

Das wird auch imho deutlich, wenn man sich die Unit-Section der beiden Service-Units mal anschaut... da sieht man, dass die Reihenfolge beim Shutdown zufällig sein muss..

Die Shutdown-Reihenfplge ist keineswegs zufällig. Es wird genau in der entgegengesetzten Reihenfolge abgebaut, wie es beim Boot aufgebaut wird.

[TomL]

wpa_supplicant wird entweder vom NWM oder von ifup gestartet, je nach dem, ob man NWM oder /etc/network/interfaces verwendet. Beendet wird wpa_supplicant entweder, wenn NWM beendet wird oder wenn ifdown ausgeführt wird.

Das ist falsch! Als Daemon läuft es unabhängig von NWM oder ifup.... guckstu "enabled" .... und dementsprechend reagiert die Unit auch unabhängig von NWM oder ifup beim shutdown.... und deswegen knallts fast vorhersagbar bei remote-mounts, die durch systemd zwar ordnungsgemäß vor dem Netzwerk-Shutdown geschlossen werden sollen, denen aber wpa-supplicant schon vorher die Verbindung wegknallt.... ich konnte diese Stopjobs mit lxde und xfce beliebig reproduzieren.

Code: Alles auswählen

# systemctl status wpa_supplicant.service
● wpa_supplicant.service - WPA supplicant
   Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-03-28 18:57:06 CET; 1min 32s ago
 Main PID: 50 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
           └─50 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant

Die Shutdown-Reihenfplge ist keineswegs zufällig. Es wird genau in der entgegengesetzten Reihenfolge abgebaut, wie es beim Boot aufgebaut wird.

Wenn die Unit-Sections keine entsprechenden Kriterien enthalten, gibts auch keine eindeutige Reihenfolge... siehe die beiden Ausschnitte oberhalb. Aus gleichlautenden Abhängigkeiten kann keine dauerhaft gleichbleibende eineutige Reihenfolge abgeleitet werden. Aber ich klinke mich deshalb jetzt hier aus... weil es zuviele individuelle Variablen gibt, die auf einmal dann doch wieder einen neuen individuellen Aspekt einbringen können. Außerdem kenne ich auch die KDE nicht (mehr).... was die treibt fand ich schon immer ein wenig undurchschaubar.

Ich bleibe erst mal dabei... solange, bis es widerlegt wird... conflict-statement rein in die Unit und gut is.... etwas anderes und mehr eindeutiges fällt mir dazu leider auch nicht ein.

[Heliosstyx]

Folgende nachprüfbare Fakten zu meinem Problem halte ich jetzt einmal fest, um klar zu stellen, dass das ein spezifisches Problem ist, um Anderen bei der Eingrenzung in Zukunft zu helfen:

1. Es handelt sich hier um ein dual-boot System mit Debian Buster KDE und Windows 10, läuft nativ, keine VM's, WLAN ist die alleinig beutzte Netzwerkverbindung.
2. Das gleiche System hat unter Benutzung von Fedora 28/29, Netrunner 19, Manjaro, alle mit Plasma 5,und sonst gleichen Parametern, keinerlei Probleme gezeigt.
3. Das jetzige System wurde via Debian-testing-kde(Buster) Live ISO installiert, also mit Calamares als Installer.
4. Die eingebaute Uhr (RTC) ist jetzt lokal synchronisiert und nicht mehr UTC (Debian Standard). Vorgangsweise ist entprechendes Debian Wiki...

Alle Systeme laufen auf hochwertigen HP Notebooks, hauptsächlich mit Intel Systemarchitektur.

Ich werde die Test-Ergebnisse in ein paar Tagen hier wieder publizieren, damit ihr seht, ob sich das Problem so lösen lässt. Ich werde auch überprüfen, ob Windows hier einen Einfluss hat.

[TomL]

Folgende nachprüfbare Fakten zu meinem Problem halte ich jetzt einmal fest, um klar zu stellen, dass das ein spezifisches Problem ist, um Anderen bei der Eingrenzung in Zukunft zu helfen:

Bleibt das Verhalten trotzdem konstant, nachdem Du Conflicts=shutdown.target in die Service-Unit eingetragen hast (nach reboot oder daemon-reload)?

[Heliosstyx]

Thomas: ich habe derzeit noch keine "Unit" eingetragen, da ich iterativ vorgehe, zuerst die Uhr--> Test, dann die von Dir empfohlene Unit --> Test. Anders werde ich es nicht machen, sonst bricht durch die Interdependenzen, die hier offensichtlich reichlich vorhanden sind, nur das Chaos aus. Strukturiertes Testen ist hier unabdingbar, es ist auch nicht erwiesen, dass Buster selbst nicht die Ursache ist, da es eigentlich noch nicht fertig ist(Stable). Ihr hört von mir jedenfalls, was los ist. Danke nochmals an alle Beitragenden.

[JTH]

Ein Einwurf zu später Zeit:

Das Problem scheint, soweit ich das überflogen habe, ja zu sein, dass die Netzwerkverbindungen zu früh getrennt werden (?!)

Beim Network-Manager kann man (WLAN-)Verbindungen als systemweite oder nur „benutzereigene“ Verbindungen konfigurieren. Bei systemweiten Verbindungen verhält sich der Network-Manager ähnlich zu ifupdown und co., Verbindungen werden früh beim Boot aufgesetzt und spät beim Herunterfahren getrennt.

Bei benutzereigenen Verbindungen ist das nicht so, die werden abgewürgt, sobald sich der betreffende Benuter abmeldet. Dienste, die vom Netzwerk abhängen, werden dabei mehr oder weniger ignoriert.

Du scheinst dein WLAN als benutzereigene Verbindung konfiguriert zu haben, Heliosstyx:

Meine WLAN Verbindung (ich verwende nur WLAN)wird erst hergestellt, wenn nach dem Login der Plasma Desktop vollständig sichtbar und geladen ist und erst dann stellt Plasma die WLAN Verbindung automatisch her.

Bevor du größere andere Umbauten machst, probier mal, ob es etwas ändert, dein WLAN zu einer systemweiten Verbindung zu machen. Unter Gnome gibt es bei den Netzwerkverbindungen ein Häkchen „Make available to other user“/etwa „Verbindung für andere Benutzer verfügbar machen“. Ich nehme mal an, bei KDE gibt es einen ähnlichen Haken.

[MSfree]

Ich nehme mal an, bei KDE gibt es einen ähnlichen Haken.

Mir ist so ein Häkchen bisher unter KDE nicht aufgefallen. KDE verwendet Kwallet als verschlüsselten Paßwortspeicher, unter anderem auch für die WLAN-Keys. Man kommt also erst ins WLAN, wenn man die Kwallet mit dam entsprechenden Paßwort aufgeschlossen hat. Eine Systemweite WLAN-Konfigurierung ist dadurch via Networkmanager unmöglich.

[willy4711]

Bevor du größere andere Umbauten machst, probier mal, ob es etwas ändert, dein WLAN zu einer systemweiten Verbindung zu machen. Unter Gnome gibt es bei den Netzwerkverbindungen ein Häkchen „Make available to other user“/etwa „Verbindung für andere Benutzer verfügbar machen“. Ich nehme mal an, bei KDE gibt es einen ähnlichen

Eine Systemweite WLAN-Konfigurierung ist dadurch via Networkmanager unmöglich.

Ich nehme mal an. JTH meint dieses Häkchen, das ist beim Network Manager für alle Verbindungen zumindest unter KDE,
Gnome und Xfce zu Verfügung steht

[JTH]

JTH meint dieses Häkchen

Exakt.

[novalix]

Man bedenke jedoch:

Code: Alles auswählen

root@tristam:~# grep -v ^# /etc/network/interfaces

auto lo
iface lo inet loopback

und

Code: Alles auswählen

root@tristam:~# ss -tlpen | grep 3306
LISTEN    0         80               127.0.0.1:3306             0.0.0.0:*        users:(("mysqld",pid=903,fd=17)) uid:124 ino:26206 sk:1 <->

Mariadb hat in der Default-Einstellung mit den Interfaces, die über den network-manager erzeugt und konfiguriert werden, nichts am Hut.

[Heliosstyx]

Hier ist das Testergebnis: Die Lösung beide Betriebssysteme die gleiche "Zeitsprache2 sprechen zu lassen.

Entweder Windows 10 und Debian UTC verwenden lassen oder beide die Lokalzeit verwenden lassen. Die Zeit in Windows 10 geht nicht mehr nach, um die Zeit bei Aufbau der Internetverbindung zu korrigieren (RTC!) und Debian 10 schlägt beim Start nicht eine Stunde auf, um das ganze bei der Netzwerk-Zeitsynchronisation wieder zurückzunehmen. Jetzt zeigt auch die RTC die exakte Zeit. Jetzt kann problemlos zwischen beiden Betriebssystemen gewechselt werden ohne gegenseitige Beeinflussung. Der entsprechende Debian Wiki Eintrag widmet Windows sogar einen eigenen Eintrag. Auch wenn es manche nicht wahr haben wollen, es gibt mehr Windows /Linux Benutzer als es sich viele vorstellen können und das aus ganz pragmatischen Gründen (das Beste aus zwei Welten). Danke an Alle für die Unterstützung. Aus eurer Diskussion habe ich viel gelernt.