Verzögerungen beim Herunterfahren.
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Verzögerungen beim Herunterfahren.
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! ).
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!
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! ).
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!
Re: Verzögerungen beim Herunterfahren.
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 mitottonormal hat geschrieben:18.12.2017 10:07:40Ich 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.
Code: Alles auswählen
journalctl -b -1
Re: Verzögerungen beim Herunterfahren.
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:
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
(dort sollte man auch leichter erkennen können, wann das Herunterfahren begonnen hat)
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
Code: Alles auswählen
# journalctl -b -1 -p7
Re: Verzögerungen beim Herunterfahren.
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-Meldungensmutbert hat geschrieben:18.12.2017 12:13:08Im Log sehe ich auch nichts, aber ich bezweifle auch, dass der network-manager die Verzögerung verursacht.
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.
Re: Verzögerungen beim Herunterfahren.
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.)
(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.)
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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.
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?
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.
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?
Re: Verzögerungen beim Herunterfahren.
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
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?
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?
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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.
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:
ausgeführt und das dabei erhalten:
http://nopaste.debianforum.de/40095
Das war jetzt ohne Fehler beim Herunterfahren. Ist da trotzdem etwas auffälliges?
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
Ich habe trotzdem mal nach 2 Neustarts:
Code: Alles auswählen
journalctl -b -1 -p7
http://nopaste.debianforum.de/40095
Das war jetzt ohne Fehler beim Herunterfahren. Ist da trotzdem etwas auffälliges?
Re: Verzögerungen beim Herunterfahren.
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:
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
Re: Verzögerungen beim Herunterfahren.
Interessant wirds ab der 1. Meldung, die nach dem Shutdown kommt... und alles darauf folgende:
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.
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...
Damit kann man auch prima nach Stichworten suchen, einmal den Suchbegriff eingeben und dann mit Taste "n" zum nächsten gefundenen springen.
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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.
Ich werde es dann unverzüglich hier berichten.
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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
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.
Dann fuhr ich den Rechner herunter und hatte dabei die Verzögerung. Also neugestartet und
Code: Alles auswählen
journalctl -b -1 -p7 | cat
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.
- 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.
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.)
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.)
Re: Verzögerungen beim Herunterfahren.
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.
@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.
- 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.
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.TomL hat geschrieben: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.
Aufbauend auf den so gewonnenen Erkenntnissen habe ich das hier geschrieben: https://wiki.debianforum.de/NFSv4-Mini-Howto
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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?
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?
Re: Verzögerungen beim Herunterfahren.
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
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.
Es sind 1 Minute und 36 Sekunden.ottonormal hat geschrieben:18.12.2017 10:07:40[…]
Dann beim Herunterfahren wieder "gefühlte" 5 Minuten Verzögerung (ich weiß, dass es weniger ist! ).
[…]
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.
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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?
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?
Re: Verzögerungen beim Herunterfahren.
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 ).ottonormal hat geschrieben:18.12.2017 22:02:48...
Gibt es eine einfache Möglichkeit Claws-Mail automatisch zu beenden bevor der Neustart oder das Herunterfahren beginnt?
Nun, es gibt die Pakete lxhotkey-gtk und lxhotkey-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.
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
...schön geschrieben.
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.
Re: Verzögerungen beim Herunterfahren.
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.ottonormal hat geschrieben:18.12.2017 22:02:48[...]
Gibt es eine einfache Möglichkeit Claws-Mail automatisch zu beenden bevor der Neustart oder das Herunterfahren beginnt?
(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
Code: Alles auswählen
KillUserProcesses=yes
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
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?
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?
Re: Verzögerungen beim Herunterfahren.
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...
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...
Re: Verzögerungen beim Herunterfahren.
Das ist einfach, braucht nur mehr Einrichtungszeit.ottonormal hat geschrieben:18.12.2017 23:28:02...
Aber Ernst beiseite, ich meinte wirklich etwas Einfaches.
...
Meinst Du mit " ...anders... " einen anderen Mailer?ottonormal hat geschrieben: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.
...
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
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.
- ottonormal
- Beiträge: 3404
- Registriert: 20.01.2014 22:25:29
Re: Verzögerungen beim Herunterfahren.
@smutbert
Vielen Dank. Das hört sich gut an und hat mich veranlasst, meine Einstellung zu Systemd zu ändern . 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 .
Noch mal vielen Dank für alle Antworten.
Vielen Dank. Das hört sich gut an und hat mich veranlasst, meine Einstellung zu Systemd zu ändern . 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 .
Noch mal vielen Dank für alle Antworten.