Verzögerungen beim Herunterfahren.

KDE, Gnome, Windowmanager, X11, Grafiktreiber und alles was dazu notwendig ist. Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 10:07:40

Hallo,

nicht immer, aber immer öfter!
Verzögerungen beim Herunterfahren des Rechners von mehreren Minuten. Das Thema gab's hier ja schon mehrfach, geholfen hat bei mir noch nichts.
Erst gestern Abend. Der Rechner lief mehrere Stunden ohne Besonderheiten, die letzte halbe Stunde sicher nur im Leerlauf. Dann beim Herunterfahren wieder "gefühlte" 5 Minuten Verzögerung (ich weiß, dass es weniger ist! :roll: ).

Hier mal die syslog: http://nopaste.debianforum.de/40094
Lässt sich daraus etwas schließen?

Ich habe dieses Problem seit der Einführung von "systemd". Ich weiß, dass man Kritik daran hier im Forum nicht äußern darf, schon die Erwähnung des Wortes ist frevelhaft, fast schon wie eine Religion. Ich tu's aber trotzdem. Ich hatte gedacht, da der Fehler ja nicht immer auftritt, ich könnte mich irgendwann daran gewöhnen und mich damit abfinden, es nervt aber einfach nur noch! :evil:

TomL

Re: Verzögerungen beim Herunterfahren.

Beitrag von TomL » 18.12.2017 11:29:10

ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 10:07:40
Ich habe dieses Problem seit der Einführung von "systemd". Ich weiß, dass man Kritik daran hier im Forum nicht äußern darf, schon die Erwähnung des Wortes ist frevelhaft, fast schon wie eine Religion. Ich tu's aber trotzdem.
Ich finde das völlig ok, wenn man nachweisen kann oder begründeten Verdacht hat, dass der Fehler wirklich bei systemd liegt oder das systemd das vorsätzlich verursacht.... dann sollte man das sogar wirklich offen sagen. Ich glaube allerdings, dass systemd mit diesem Problem hier überhaupt nix zu tun hat... für mich sieht es viel mehr nach einem Problem mit dem Networkmanager aus. Leider empfinde ich das syslog hier als nicht sehr hilfreich. Besser wäre es imho, die echten systemd-journald-Einträge zu sehen, die beim Herunterfahren geschrieben werden. rsyslog schreibt ja nur das, was es von journald geliefert bekommt... keine Ahnung, wie vollständig das ist. Zumindest habe ich den Eindruck,dass es nicht vollständig ist und sich mehr oder weniger auf Kernel-Messages reduziert. Sofern systemd-journald "persistent" eingerichtet ist, könnte man sich den letzten Shutdowndown-Verlauf mit

Code: Alles auswählen

journalctl -b -1 
anschauen. Ich würde das mal einrichten und dann schauen, ob man vielleicht damit den Verursacher der Hänger besser lokalisieren oder zumindest eingrenzen kann.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 18.12.2017 12:13:08

Im Log sehe ich auch nichts, aber ich bezweifle auch, dass der network-manager die Verzögerung verursacht.

Und ich würde auch vorschlagen, dass du (zumindest vorübergehend) dafür sorgst, dass das journal von systemd dauerhaft gespeichert wird. Dazu legst du einfach das Verzeichnis /var/log/journal an:

Code: Alles auswählen

# mkdir /var/log/journal
Danach braucht es einen Neustart, dass die Änderung wirksam wird, dh nach dem übernächsten Herunterfahren kannst du hier das journal posten, so wie TomL es vorgeschlagen hat, eventuell zusätzlich noch mit der Option -p7, damit wirklich alle Meldungen erscheinen

Code: Alles auswählen

# journalctl -b -1 -p7
(dort sollte man auch leichter erkennen können, wann das Herunterfahren begonnen hat)

TomL

Re: Verzögerungen beim Herunterfahren.

Beitrag von TomL » 18.12.2017 12:37:29

smutbert hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 12:13:08
Im Log sehe ich auch nichts, aber ich bezweifle auch, dass der network-manager die Verzögerung verursacht.
Mein Verdacht ging in die Richtung (weil es sich hier anscheinend um einen wifi-Connect handelt), das der NWM beim Shutdown die Verbindung zu früh trennt, obwohl vielleicht auf der Verbindung noch irgendwas laufen möchte... und "derjenige", dem die Verbindung gekappt wurde, versucht verzweifelt, wieder an seine auf der anderen Seite des Netzwerks liegenden "Sachen" zu kommen oder die abgerissene Verbindung wiederherzustellen. Ich lese da haufenweise already-pending-Meldungen
wpa_supplicant[867]: wlp3s0: Reject scan trigger since one is already pending

Keine Ahnung, ob das eine Ursache sein kann, aber mir ist's halt aufgefallen. Im Moment sehe ich da sonst auch nix auffälliges... das Log ist ja leider sehr knapp.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 18.12.2017 13:03:38

Das kann sein und würde zu 5 Minuten Verzögerung passen.
(Ich hab gedacht der Befehl zum Herunterfahren ist erst um 01:27, also danach gekommen, weil sich die iwlwifi-, network-manager- und wpasupplicant-Meldungen ja durch das ganze Log ziehen.)

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 13:06:09

Danke für die Antworten.
Werde ich also mal versuchen das eingerichtet zu bekommen.
Aussagekräftig wird das dann aber erst wenn auch der Fehler auftritt, oder? Wenn ich den bewusst herbeiführen will, weiß ich nicht, ob er mir den Gefallen tut. Dann tritt bestimmt der Vorführeffekt ein. :wink:

Ich will mal versuchen den Fehler noch etwas genauer zu beschreiben:
Ich weiß nicht, wann das mit systemd losging, nicht mal genau, was systemd überhaupt ist.
Das erste Mal, dass es mir auffiel war auf einer Testinstallation mit Manjaro (Version weiß ich nicht mehr) auch mit systemd, da trat der Fehler jedenfalls immer auf.
Dann bei Jessie (war wohl noch im Frostzustand, oder schon davor?) hatte ich damals schon als testing installiert, seitdem bei Stretch sowieso, das ich aber auch erst im Frostzustannd installiert habe. Dann hatte ich immer auch noch ein Linux-Mint oder Ubuntu installiert. Da war es auch erst, als da systemd eingeführt wurde, vorher war es da nicht.
Also muss es doch irgendwie mit systemd zusammenhängen, oder?

Da hier auch "wifi-Connect" erwähnt wurde, das ist doch zuständig für WLAN, oder? Bei dem Rechner handelt es sich zwar um einen Laptop, WLAN nutze ich aber trotzdem nur in ganz seltenen Ausnahmesituationen. Meist nur bei Neuinstallation zum Ausprobieren. Normal ist immer eine Netzverbindung per Kabel in Betrieb.

Dann muss ich auch noch erwähnen, dass es nur auf meinem Haupt-Arbeitsrechner auftritt (Tuxedo Book DX1702). Auf dem Rechner meiner Frau habe ich das noch nie erlebt (ebenfalls mit Debian Stretch), da dauert das Herunterfahren nicht mehr als 2 Sekunden.
Kann also auch die Hardware dazu beitragen?

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 18.12.2017 13:19:24

Ja, wifi=wlan und ja der Fehler muss schon auftreten. Wenn der Vorführeffekt dauerhaft eintritt, können wir den Thread ja auch als erledigt betrachten :wink:

Ob es nun etwas mit systemd zu tun hat oder nicht werden wir sehen, wenn es das nächste Mal auftritt. Kann es sein, dass du jedes Mal vor dem Auftreten irgendetwas bestimmtes gemacht hast?
(Über das Netzwerk irgendetwas kopiert, eine bestimmte Anwendung gestartet oder irgendetwas in der Art.)
Gab es am Bildschirm keine Meldung wie "a stop job is running...", als es so lange gedauert hat?

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 13:39:16

Eine Meldung gibt es bei dem Fehler nicht, nur ein blinkender Cursor.
Irgendetwas besonderes gemacht habe ich eigentlich auch nicht, jedenfalls nicht wissentlich. Es gab mal eine Zeit, da kam der Fehler häufig vor wenn ich einen Fernseh-Livestream mit VLC geschaut habe, z.B.

Code: Alles auswählen

vlc /PFAD_ZUR_M3U_DATEI/DasErste.m3u8
Da habe ich das öfters gehabt, aber auch nicht immer. In letzter Zeit ist mir das aber auch nicht mehr besonders aufgefallen. Es passiert ja auch ohne VLC-Livestream.


Ich habe trotzdem mal nach 2 Neustarts:

Code: Alles auswählen

journalctl -b -1 -p7   
ausgeführt und das dabei erhalten:
http://nopaste.debianforum.de/40095

Das war jetzt ohne Fehler beim Herunterfahren. Ist da trotzdem etwas auffälliges?

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 18.12.2017 13:57:04

Nein, da würde ich auch nichts erwarten. Aber das Log ist auch unvollständig, du hast nur die ersten paar Zeilen vom Starten gepostet.
journalctl gibt die Meldungen mit einem Pager aus, dh du kannst/musst mit <Ende>, <Pos1> und <PageUp>, <PageDown> in der Ausgabe navigieren oder du lässt dir das Log ohne Pager ausgeben, was zum Beispiel so geht:

Code: Alles auswählen

journalctl -b -1 -p7 | cat

TomL

Re: Verzögerungen beim Herunterfahren.

Beitrag von TomL » 18.12.2017 14:12:23

Interessant wirds ab der 1. Meldung, die nach dem Shutdown kommt... und alles darauf folgende:

Code: Alles auswählen

Dez 17 23:16:24 thomaspc systemd-logind[2131]: System is powering down.
Dez 17 23:16:24 thomaspc systemd[1]: Stopping User Manager for UID 108...
Alternativ zum Cat-Befehl kann man auch einfach in der regulären Journal-Ausgabe einen Schrägstrich "/" tippen und in der Eingabezeile dann "powering" eingeben... dann springt er gleich auf die erste richtige Zeile. Und ab da scrollt man langsam runter und schaut, wo es hängt. Damit lässt es sich imho etwas bequemer scrollen.

Damit kann man auch prima nach Stichworten suchen, einmal den Suchbegriff eingeben und dann mit Taste "n" zum nächsten gefundenen springen.

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 14:17:19

Ahaa, ja danke, dann werde ich mal heute und die kommenden Tage zwischendurch immer wieder mal Neustarts machen. Irgendwann muss der Fehler dann ja wieder kommen, hoffe (?) ich jedenfalls.
Ich werde es dann unverzüglich hier berichten.

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 18:31:57

So, nach mehreren "erfolglosen" Versuchen hat es nun geklappt. Der Rechner war ca. 2 1/2 Std. in Betrieb. Ich habe nur etwas gesörft und in Calibre etwas gearbeitet. Mehr weiß ich schon gar nicht mehr. Auf jeden Fall nichts Besonderes, Leerlauf war auch reichlich.
Dann fuhr ich den Rechner herunter und hatte dabei die Verzögerung. Also neugestartet und

Code: Alles auswählen

journalctl -b -1 -p7 | cat
ausgeführt. Das ist das Ergebnis:

http://nopaste.debianforum.de/40099

Tasächlich werden da auch Meldungen mit "NetworkManager" und "error" angzeigt. Ich habe aber keine Ahnung, was das alles bedeutet.

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: Verzögerungen beim Herunterfahren.

Beitrag von jph » 18.12.2017 19:06:02

Ich habe in deinen Logs Hinweise auf NFS gefunden. Wenn du NFS-Mounts eingebunden hast und NetworkManager und systemd verwendest, dann scheinen diese Hänger derzeit leider unvermeidlich zu sein. NetworkManager und systemd können nicht wirklich miteinander: NetworkManager trennt die Netwerkverbindung, bevor systemd die NFS-Mounts aushängt.

Ich nutze NFS nur unregelmäßig und habe mir dafür eine automount-Unit eingerichtet, die die NFS-Mounts nach einigen Minuten der Inaktivität wieder aushängt. Bei ausgehängten NFS-Mounts fährt der Rechner zügig runter; bei noch eingehängten Mounts darf ich 1:30 Minuten warten.

Du kannst ja mal Versuche anstellen mit und ohne NFS-Mounts. (Achte bitte auf weitere Netzwerk-Dateisysteme wie SMB.)

TomL

Re: Verzögerungen beim Herunterfahren.

Beitrag von TomL » 18.12.2017 19:11:35

Auf die Schnelle überflogen tippe ich auf dm-crypt, welches entweder zu früh geschlossen wird und Programm oder Dienste wollen noch mal darauf zugreifen, die dann hängen. Oder das crypt-Device kann nicht geschlossen werden, weil ein Prozess noch offene Aktionen darauf hat und es hängt deshalb.

@jph, das passiert eigentlich nur bei WLAN-Verbindungen, wenn zu früh das WLAN-Interface geschlossen wird... möglicherweise, weil wpa-supplicant zu früh trennt.Bei Kabelverbindungen habe ich das noch nicht beobachtet.

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: Verzögerungen beim Herunterfahren.

Beitrag von jph » 18.12.2017 19:44:45

TomL hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 19:11:35
@jph, das passiert eigentlich nur bei WLAN-Verbindungen, wenn zu früh das WLAN-Interface geschlossen wird... möglicherweise, weil wpa-supplicant zu früh trennt.Bei Kabelverbindungen habe ich das noch nicht beobachtet.
Bei mir tritt das sowohl bei Laptop (WLAN) und Desktop (Ethernet), Netzwerkmanagement in beiden Fällen per NetworkManager, auf. Ich habe das ausgiebig durchgetestet und konnte das auf noch gemountete NFS-Exporte zurückführen.

Aufbauend auf den so gewonnenen Erkenntnissen habe ich das hier geschrieben: https://wiki.debianforum.de/NFSv4-Mini-Howto :wink:

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 19:59:41

Also, ich weiß wie "NFS" geschrieben wird, mehr nicht. Und dm-crypt?
Meine beiden Systempartitionen für Jessie und Stretch sind ja verschlüsselt. hängt es damit zusammen?
Der Rechner meiner Frau ist nicht verschlüsselt, da gibt's auch diese Probleme nicht. Hat das eine Bedeutung?

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 18.12.2017 21:06:48

Ich hab den Verdacht, dass die eineinhalb Minuten Verzögerung an etwas anderem liegen, denn nun wissen wir immerhin schon einmal, dass du damit recht hast
ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 10:07:40
[…]
Dann beim Herunterfahren wieder "gefühlte" 5 Minuten Verzögerung (ich weiß, dass es weniger ist! :roll: ).

[…]
Es sind 1 Minute und 36 Sekunden.

Direkt verantwortlich für die Verzögerung scheinen timeouts beim Stoppen der Verschlüsselung zu sein, vermutlich weil irgendwelche Programme sich nicht beenden wollen und noch darauf zugreifen, ein Beispiel, das im Log auftauch ist claws-mail.
Vom Killen von claws-mail an geht der Rest recht hurtig (5 Sekunden).

Erkenntnis Nummer 2 ist und das soll jetzt keineswegs wie ein Vorwurf klingen, dass du meiner Auffassung nach ziemlich viele Dienste laufen hast, Modemmanager, Samba, nfs, Turboprint, bluetooth, Diskmanager (da hab ich erst nachlesen müssen, wozu das überhaupt gut sein soll) und auch viele Dateisysteme, die in irgendeiner Form gemountet sind (über gvfs, truecrypt).

Als erste Maßnahme würde ich etwas genauer auf claws-mail achten und ob das nur auftritt, wenn das beim Abmelden gelaufen ist.

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 22:02:48

Danke, das ist schon mal 'ne Ansage.
Claws-Mail ist tatsächlich im Autostart eingetragen und wird beim Starten versteckt und in den Panel-Infobereich minimiert. Beim Herunterfahren beende ich händisch Claws-Mail nie. Das könnte ich ja leicht schon mal ändern, zumindest bis ich weiß, dass das der Übeltäter ist oder auch nicht.

turboprint ist ein Druckertreiber ohne den ich meinen Drucker nicht vernünftig zum Laufen bringe. Der hat sich selbst in den Autostart gemogelt, hab ich jetzt auch erst gemerkt und unterbunden.

Genau so hat Shutter es gemacht. Den habe ich auch deaktiviert.

Jetzt werde ich das also erst mal weiter beobachten. Wenn der Fehler dann nicht mehr auftritt, eine Aktion nach der anderen wieder rückgängig machen.

Gibt es eine einfache Möglichkeit Claws-Mail automatisch zu beenden bevor der Neustart oder das Herunterfahren beginnt?

Benutzeravatar
Revod
Beiträge: 3788
Registriert: 20.06.2011 15:04:29
Lizenz eigener Beiträge: MIT Lizenz

Re: Verzögerungen beim Herunterfahren.

Beitrag von Revod » 18.12.2017 22:33:37

ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 22:02:48
...
Gibt es eine einfache Möglichkeit Claws-Mail automatisch zu beenden bevor der Neustart oder das Herunterfahren beginnt?
Die gäbe es, ist etwas aufwendig. Unter, damals Testing( Stretch ) nutzte ich " xhotkeys " , der den Befehl für das Script zu reboot, runter fahren und log-out hatte. Unter Jessie funktionierte der Befehl einwandfrei, erst nachdem Jessie zu Stretch( Testing ) wurde galten die Scripte mit dem " reboot und shutdown " Befehl nicht mehr ( Weil noch verschiedene andere Sachen im Arg waren habe ich nicht nach der Behebung gesucht ).

Nun, es gibt die Pakete Debianlxhotkey-gtk und Debianlxhotkey-plugin-openbox, womit Du die richtige Befehle erst Mal für die Tastenkürzel fest legen kannst und als wirklich sehr gute Alternative zu xhotkeys, dass sich nicht mehr in den Debian Repos befindet ( Oder nie befunden hat. Lxhotkey ist auch nicht so alt, seid ca. 6 - 7 Monate in den Repos ).

1. Befehl = Claws-Mail und mit auch andere Prozesse zu beenden
2. Befehl einen " Sleep " von 1 Sekunde um Sicher zu stellen, dass alles beendet ist.
3. Befehl für das Shutdown, reboot oder logout.

Wenn das alles gelöst wird mit Hilfe von Scripte kannst Su dann auch " starter.desktop " anlegen, die auch per Klick auf die jeweilige Scripte zugreifen.

Doch wie gesagt, meine Scripte funktionieren nicht mehr unter Stretch ( Den ich immer noch nicht neu aufgesetzt habe ).
Systemd und PulseAudio, hmmm, nein danke.

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 18.12.2017 23:28:02

Revod hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 22:33:37
ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 22:02:48
Gibt es eine einfache Möglichkeit...
Die gäbe es, ist etwas aufwendig...
...schön geschrieben. :mrgreen:
Aber Ernst beiseite, ich meinte wirklich etwas Einfaches.

Eigentlich brauche ich Claws-Mail oder ein anderes Mailprogramm gar nicht mehr. Ich habe es nur, weil ich in meinem Posteo-Konto 3 Alias-Adressen habe und im Webmailer dafür Filter eingerichtet habe wodurch Mails an diese Alias-Adressen automatisch in den entsprechenden Ordnern landen. Das funktioniert auch wunderbar nur erkennt mein Mailwatcher das nicht und gibt dann auch nicht Laut.

Da kommt Claws-Mail zum Einsatz. Da können diese Ordner in der Benachrichtigung ausgewählt werden.
Vielleicht müsste ich mir dafür etwas anderes einfallen lassen. Jedenfalls so, dass ich auf Claws-Mail nicht mehr angewiesen bin.

Das wäre dann aber ein neuer Faden.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 18.12.2017 23:36:23

ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 22:02:48
[...]
Gibt es eine einfache Möglichkeit Claws-Mail automatisch zu beenden bevor der Neustart oder das Herunterfahren beginnt?
Nach etwas genauerer Überlegung könnte das mit Clawsmail auch daran liegen, dass die Netzwerverbindung gekappt wurde bevor sich claws-mail beendet hat und dann hat es mangels Netzwerk erst recht gehakt bei claws-mail.
(Das ließe dann auch die Möglichkeit offen, dass es rein gar nichts mit der Verschlüsselung zu tun hat!)

Dagegen könntest du einmal testweise in »/etc/systemd/logind.conf« die Zeile

Code: Alles auswählen

#KillUserProcesses=no
in

Code: Alles auswählen

KillUserProcesses=yes
ändern (# entfernen nicht vergessen). Dann sollten bei der Abmeldung alle Programme des Benutzers zwangsweise beendet werden.

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 19.12.2017 00:12:29

Ja, danke, genau so etwas meinte ich mit "einfach". Ich habe es jetzt so gemacht und Claws-Mail so belassen wie es war. Nun schaun wir mal ob das was bringt.
Hab mal zum Testen 2 Neustarts gemacht, Herunterfahren braucht knappe 10 Sekunden. Ich habe das Gefühl, das könnte es gewesen sein.
Kann es eigentlich keine Probleme geben wenn immer alle Prozesse einfach so abgewürgt werden?

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Verzögerungen beim Herunterfahren.

Beitrag von smutbert » 19.12.2017 00:22:40

Die Prozesse werden nicht zwangsweise abgewürgt. Der große Unterschied ist, dass es mit systemd-login normalerweise grundsätzlich erlaubt ist, dass nach der Abmeldung Prozesse des Benutzers weiterlaufen (was durchaus sinnvoll, aber auch lästig sein kann).

Beim Beenden der Prozesse des Benutzers passiert aber auf jeden Fall im wesentlich dasselbe - zuerst werden sie freundlich gebeten sich zu beenden und wenn sie das (lange genug) nicht tun, dann erst werden sie abgewürgt. Es ändert sich nur wann das passiert (direkt beim Abmelden oder beim Herunterfahren).


Entscheidend ist hier halt auch noch, dass systemd bei systemweiten Diensten normalerweise davon weiß, dass irgendein Prozess zum Beispiel eine Netzwerkverbindung braucht, dh er beendet zuerst den Prozess und fährt dann erst das Netzwerk herunter (funktioniert trotzdem nicht immer).
Bei normalen Anwendungen des Benutzers weiß systemd dagegen nichts davon. Wenn also nach der Abmeldung ein Prozess übrig geblieben ist, dann kümmert sich systemd möglicherweise erst nach dem Beenden des Netzwerks darum und wenn das nun ein Mailclient ist, der sich zum Beispiel noch von einem Server abmelden wollte, dann kann man den unter Umständen lange freundlich bitten sich zu beenden, bevor ein Timeout auftritt...

Benutzeravatar
Revod
Beiträge: 3788
Registriert: 20.06.2011 15:04:29
Lizenz eigener Beiträge: MIT Lizenz

Re: Verzögerungen beim Herunterfahren.

Beitrag von Revod » 19.12.2017 10:45:49

ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 23:28:02
...
Aber Ernst beiseite, ich meinte wirklich etwas Einfaches.
...
Das ist einfach, braucht nur mehr Einrichtungszeit.
ottonormal hat geschrieben: ↑ zum Beitrag ↑
18.12.2017 23:28:02
...
Vielleicht müsste ich mir dafür etwas anderes einfallen lassen. Jedenfalls so, dass ich auf Claws-Mail nicht mehr angewiesen bin.
...
Meinst Du mit " ...anders... " einen anderen Mailer?

Doch wenn die Anweisung von smutbert auch klappt wäre es doch prima.

Übrigens, das ist ein Befehl unter PCLinuxOS / lxde mit xhotkeys und ohne Systemd super klappt, als Beispiel einen reboot.

Code: Alles auswählen

command = pkill qmmp | pkill xhotkeysd | pkill gkrellm | reboot
Doch leider unter Stretch( Testing ) und mit Systemd klappte es irgend wann nicht mehr.

Hatte dieses Sommer auch viel danach recherchiert, doch ich fand nichts darüber. Nur das übliche für lxde, dass nachdem ich auf das Starter des runter fahren geklickt hatte das übliche logout usw. Dialog mit alle den Optionen erschien. Somit war ein runter fahren ohne vorheriges Geklicke nicht mehr möglich ( 1. Ausschalten und 2. nochmal ein Klick auf das Dialog Knopf, Ausschalten ).

Wenn vielleicht jemand für lxde den richtigen Befehl oder was man im Systemd alles umstellen muss bis es mit einen Klick und ohne weitere Rückfragen rebooten und shutdown bewirkt, oder einen Tastenkürzel einen Befehl dafür übergibt wäre es für mich auch hilfreich.

Leute ich weiss, es ist etwas OT, doch wenn es so auf die schnelle machbar wäre... :)
Systemd und PulseAudio, hmmm, nein danke.

Benutzeravatar
ottonormal
Beiträge: 3404
Registriert: 20.01.2014 22:25:29

Re: Verzögerungen beim Herunterfahren.

Beitrag von ottonormal » 19.12.2017 11:08:56

@smutbert
Vielen Dank. Das hört sich gut an und hat mich veranlasst, meine Einstellung zu Systemd zu ändern :wink: . Ich hoffe, dass damit die Probleme behoben sind. Und wenn sie das sind, war es ja doch einfacher als gedacht.
Also abwarten und Tee trinken. Sollte tatsächlich der Fehler noch wieder auftauchen, wird man weitersehen.

@Revod
Nein, keinen anderen Mailer. Ich könnte aber z.B. die Alias-Ordner und die Filter dafür in den Posteo-Einstellungen wieder entfernen. Dafür dann Mails an die Aliase händisch in spezielle Ordner verschieben. Die Benachrichtigung vorher würde so aber funktionieren weil diese Mails dann ja im normalen Posteingangsordner landen.
Ja, und dann könnte ich auf Claws-Mail ganz verzichten. Oder zumindest nur bei wirklichem Bedarf starten und bei Nicht-mehr-Bedarf gleich beenden. Also kein Autostart und kein Start mehr minimiert ins Panel.
Ist vielleicht etwas kompliziert ausgedrückt, es fällt mir aber schwer einfache Themen auch einfach auszudrücken :wink: .

Noch mal vielen Dank für alle Antworten. :THX:

Antworten