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

[TomL]

Thomas: Was heißt hier Eigeninitiative: was soll ich denn noch tun? Darf ich dann bitte um die Lösung bitten.

Eigeninitiative heisst, sich konkret mit dem Inhalt von Antworten zu befassen. Ich weise deshalb ganz entspannt zum zweiten Mal darauf hin:

In meinem Folge-Post nach novalix habe ich sogar ganz konkret beschrieben, wie eine Vorgehensweise sein könnte.

[DeletedUserReAsG]

Hinwei am Rande: der Anfang der Ausgabe von journalctl -b -1 stellt gerade mal die ersten paar Millisekunden nach dem Einschalten dar. Hinweise zum Problem findest du aber allenfalls am Ende der Ausgabe (mit der Bild-runter-Taste kann man recht schnell scrollen; wenn der Pager less ist, gelangt man mit Shift+g direkt ans Ende).

[novalix]

Ok, lassen wir das mit dem journal vorläufig erst mal ruhen.

Ich habe auch, ehrlich gesagt, keine Ahnung, wie man systemd dazu bringt, seine Ausgaben so zu formatieren, dass ein Copy and Paste aus dem Pager gelingt, ohne die Hälfte abzuschneiden.

Einige interessante Informationen wären noch:
Läuft Dein Buster auf bare metal, also als natives Betriebssystem, oder in einer virtuellen Maschine?

Wie tickt die Uhr?
1. der Hardware
Mit Root-Rechten

Code: Alles auswählen

hwclock -r

2. des Betriebssystems

Code: Alles auswählen

date -R

Die Ausgaben der beiden Befehle sind zwar nicht exakt deckungsgleich, lassen sich aber ganz gut vergleichen.
Gibt es da offensichtliche Abweichungen?

[DeletedUserReAsG]

Ich habe auch, ehrlich gesagt, keine Ahnung, wie man systemd dazu bringt, seine Ausgaben so zu formatieren, dass ein Copy and Paste aus dem Pager gelingt, ohne die Hälfte abzuschneiden.

Code: Alles auswählen

journalctl --help
[…]
   --no-pager              Do not pipe output into a pager

Leute, die gerne alles mit cat garnieren, könnten auch einfach journalctl -b -1 | cat schreiben.

[TomL]

Ich habe auch, ehrlich gesagt, keine Ahnung, wie man systemd dazu bringt, seine Ausgaben so zu formatieren, dass ein Copy and Paste aus dem Pager gelingt, ohne die Hälfte abzuschneiden.

Speziell dieses Problem würde ich wie folgt lösen... das Wissen vorausgesetzt, dass ich gestern meinen Rechner kurz nach 23:00 ausgeschaltet habe:

Code: Alles auswählen

journalctl -b -1 --since "2019-03-26 23:00:00"  >/tmp/o

Danach kann ich 'o' mit einem beliebigen GUI-Editor/Viewer öffnen, markieren und und kopieren. Was mich aber interessiert, sind Deine Gedanken zur Uhr... wo ich jetzt annehme, dass da ein fundiertes Hintergrundwissen besteht, was mir fehlt und weswegen ich den Zusammenhang nicht verstehe.

[Heliosstyx]

Mein System ist ein dual-boot System mit Windows 10 und Debian Buster KDE in der aktuellen Version. Beide Betriebssystem laufen jeweils nativ, auf jeweils verschiedenen Festplatten. Die Uhrzeit-Differenzen zwischen beiden Betriebssystemen fallen insofern auf, als Windows um eine Stunde nachgeht, wenn man von Debian kommt, dieses Phänomen trat auch damals unter Linux Mint auf.

Hier die Zeitausgaben:

Code: Alles auswählen

sudo hwclock -r
[sudo] Passwort für brumm: 
2019-03-28 10:56:24.905556+01:00

Code: Alles auswählen

sudo date -R
Thu, 28 Mar 2019 10:56:55 +0100

[MSfree]

Die Uhrzeit-Differenzen zwischen beiden Betriebssystemen fallen insofern auf, als Windows um eine Stunde nachgeht, wenn man von Debian kommt, dieses Phänomen trat auch damals unter Linux Mint auf.

Debian und alle Unixe erwarten, daß die Hardwareuhr in UTC läuft. Windows hingegen erwartet, daß die Hardwareuhr in der lokalen Zeit läuft.

Man konnte aber Linux (also auch Debian) schon immer beibringen, daß die Hardwareuhr in der lokalen Zeit läuft. Bei einigen Linuxdistributionen wurde man sogar bei der Installation gefragt, ob die Hardwareuhr in der lokalen Zeit laufen soll. Bei Debian kann man das relativ leicht erreichen, in dem man die Zeile:

Code: Alles auswählen

HWCLOCKPARS=--localtime

in die Datei /etc/default/hwclock einträgt.

[Heliosstyx]

Danke für die Antwort. Was ist nun besser für Debian:

1. Auszug Debian Wiki:

In Debian the timezone for the hardware clock is configured in the file /etc/adjtime;

0.000000 14602224559 0.000000
1460224559
UTC

Edit /etc/adjtime, and change "UTC" to "LOCAL" if you want the hardware clock to be kept at local time instead of UTC.

2. oder Deine Möglichkeit.

3. Vielleicht ist die Uhrzeit wirklich das kritische Element für das mariadb shutdown-Problem: ich habe bei Ubunu folgendes gefunden: https://askubuntu.com/questions/892026/ ... ity-server

Mir ist völlig klar, dass Ubuntu nicht Debian ist, aber der Hinweis könnte die Lösung sein.

Ich habe die gleichen Systeme auf allen meinen Maschinen laufen, zeigen alle das gleiche Symptom.

[MSfree]

Danke für die Antwort. Was ist nun besser für Debian:

Ein "besser" gibt es nicht. Ich würde auf einem System, auf dem nur Linux installiert ist, die Hardwareuhr auf UTC laufen lassen, zumal UTC auch keine Umschaltung zwischen Sommer- und Winterzeit kennt.

Bei einem Dualbootsystem mit WIndows ist es sinnvoll, die Hardwareuhr auf Lokalzeit laufen zu lassen, damit man nicht bei jedem abwechselnden Boot mit der Zeit zu kämpfen hat.

Am besten ist aber, einen NTP-Server zu verwenden, dann stellt sich die Systemzei über das Netz ein und die Probleme mit der Hardwareuhr sind uninteressant.

3. Vielleicht ist die Uhrzeit wirklich das kritische Element für das mariadb shutdown-Problem: ich habe bei Ubunu folgendes gefunden: https://askubuntu.com/questions/892026/ ... ity-server
Mir ist völlig klar, dass Ubuntu nicht Debian ist, aber der Hinweis könnte die Lösung sein.

Ubuntu ist auch Linux und es verwendet die gleichen Sourcecodes für ihre Software wie Debian, wenn auch in unterschiedlichen Revisionen. So weit sind die beiden also nicht auseinander, daß man nicht auch Ubuntu-Lösungsvorschläge nach Debian übertragen könnte. Einen Versuch ist es jedenfalls wert.

[Heliosstyx]

NTP Server läuft unter Buster KDE automatisch, allerdings korrigiert das nicht die eingebaute RTC clock, damit habe ich dann das Problem, dass es sein kann, dass die Startzeiten der Dienste in der Zukunft liegen (von Windows kommend) und der Zeitdienst dann zurückstellt....

Ich werde jetzt die RTC unter Debian auf local time stellen und dann beobachten, ob sich das mariadb shutdown Problem in Luft auflöst. Wenn ich mehr weiß, publiziere ich das Ergebnis. Es scheint aber offensichtlich so zu sein, dass keiner von euch Buster mit KDE verwendet und auch nicht in Verbindung mit Windows 10, daher haben wir lange "im Nebel gestochert" und keine Lösung gefunden. Du hast aber recht, dass viele Linux Distributionen (Fedora, Manjaro, Netrunner etc.) die Lokalzeit automatisch managen und so viele Probleme mit anderen Betriebssystemen erst gar nicht auftreten

[MSfree]

NTP Server läuft unter Buster KDE automatisch, allerdings korrigiert das nicht die eingebaute RTC clock, damit habe ich dann das Problem, dass es sein kann, dass die Startzeiten der Dienste in der Zukunft liegen (von Windows kommend) und der Zeitdienst dann zurückstellt....

Naja, es kommt auf die Reihenfolge an, wie die Dienste gestartet werden, und die kenne ich auch nicht auswendig. Theoretisch sollte aber die Uhrzeit über das Netz schon sehr früh in der Startreihenfolge gestellt werden, so daß Dienste, die Netzwerk voraussetzen erst danach gestartet werden. Mariadb ist meines Wissens schon so eingerichtet, daß es nach der Netzwerkkonfiguration drankommt und daher eigentlich kein Problem mit der Uhrzeit haben sollte, es sei denn, es ist kein NTP-Server erreichbar und es wird als Notlösung auf die Hardwareuhr zurückgegriffen.

Es scheint aber offensichtlich so zu sein, dass keiner von euch Buster mit KDE verwendet

Uhrzeit und Mariadb sind völlig unabhängig vom eingesetzten Desktop und haben mit KDE überhaupt nichts zu tun. Der Desktop ist so ziemlich das letzte, das überhaupt gestartet wird, zu dem Moment ist eigentlich alles andere schon am Laufen.

Ich habe übrigens einen Rechner mit Buster und KDE am Laufen, allerdings ohne Mariadb, und vor allem, ohne Windows.

Ob es wirklich an der Uhrzeit liegt, ist aber noch fraglich. Meinem Gefühl nach ist es eher ein Reihenfolgeproblem. Ich hätte zumindest spontan darauf getippt, daß beim Shutdown das Netzwerk zu früh runtergefahren wird. Mariadb braucht aber bis zuletzt das Netzwerk. Wenn das plötzlich fehlt, wartet Mariadb auf ein Netzwerk-Timeout, also 10-20min.

Buster ist auch noch nicht endgültig fertig. Es kann gut sein, daß die Maintainer hier und da an den Systemd-Units noch feilen, um genau solche Probleme, wie du sie hast, zu beheben.

[Heliosstyx]

Das stimmt bei mir so nicht. 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. Am Anmeldebildschirm sehe ich oft auch die falsche Zeit, wenn vorher Windows genutzt wurde. Dein Ausführungen sind logisch und nachvollziehbar und dafür besten Dank.

[MSfree]

Meine WLAN Verbindung wird erst hergestellt, wenn nach dem Login der Plasma Desktop vollständig geladen ist

WLAN hatte ich natürlich nicht auf dem Radar WLAN kann man natürlich über den Networkmanager und seine Desktop-GUI konfigurieren. Es ginge aber auch über /etc/network/interfaces, was aber den Nachteil hat, daß man Flexibilität verliert, wenn der Rechner in verschiedenen WLANs betrieben werden soll.

Naja, schaun wir mal, wie sich das ganze verhält, wenn die Hardwareuhr in Lokalzeit läuft und nicht jedes Mal von Windows um eine Stunden verstellt wird.

[TomL]

....Meine WLAN Verbindung (ich verwende nur WLAN)....

Das ist das Problem... und zwar ist das sogar ein schon sehr lange bekanntes Problem. Davon betroffen sind auch Remote-Mounts, die sich auf einmal nicht mehr schließen lassen, weil das Netzwerk weg ist und die dann in 90s-Stop-Jobs enden. Das liegt daran, dass sich NWM oder wpa-supplicant gar nicht an systemd-Abhängigkeiten hält, sondern bei gewissen Triggern (z.B. poweroff) einfach die Verbindung trennt, ohne darauf zu achten, ob dieses Verbindung gerade noch gebraucht wird. Die Lösung wird in diesem Fall das genannte Conflict-Statement sein.

[willy4711]

Das liegt daran, dass sich NWM oder wpa-supplicant gar nicht an systemd-Abhängigkeiten hält, sondern bei gewissen Triggern (z.B. poweroff) einfach die Verbindung trennt, ohne darauf zu achten, ob dieses Verbindung gerade noch gebraucht wird. Die Lösung wird in diesem Fall das genannte Conflict-Statement sein.

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

Code: Alles auswählen

Mär 02 22:24:34 debiankde kernel: caller _nv001169rm+0xe3/0x1d0 [nvidia] mapping multiple BARs
Mär 02 22:24:34 debiankde systemd[1]: mariadb.service: Succeeded.
Mär 02 22:24:34 debiankde systemd[1]: Stopped MariaDB 10.3.12 database server.
[....]
Mär 02 22:24:35 debiankde systemd[1]: NetworkManager.service: Succeeded.
Mär 02 22:24:35 debiankde systemd[1]: Stopped Network Manager.
Mär 02 22:24:35 debiankde systemd[1]: Stopping D-Bus System Message Bus...

Den kompletten log :40675

Nochmal zu den logs, die uns Heliosstyx hier präsentiert hat: viewtopic.php?f=13&t=172716&start=45#p1202187
Da ist keiner komplett und anscheinend durch copy-Paste einiges durcheinander gekommen.
Der Erste endet ohne den Versuch zu Stoppen (Stopping MariaDB 10.3.13 database server...)
Der Zweite hat einen Zeitsprung nach hinten Mär 27 14:34:24 --->Mär 27 14:14:39
Der Dritte (Mär 27 14:36:4) scheint zumindest die letzten Zuckungen wiederzugeben und
mariadb scheint korrekt beendet zu sein
Beim Vierten erfahren wir, das maria gestartet ist. Aha

[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.