Verzögerter SDDM Login in KDE nach Update auf Buster
Verzögerter SDDM Login in KDE nach Update auf Buster
Hallo,
bei einem Rechner dauert der Login in KDE mit SDDM ca 60sec.
In der .xsession_error hängt der Login an dieser Stelle
dbus-update-activation-environment: setting _=/usr/bin/dbus-update-activation-environment
Hat jemand eine Idee, woran das liegen könnte?
Den Nutzer hatte ich schon komplett gelöscht und neu angelegt. Bei anderen Nutzern ist das Phänomen das Gleiche.
bei einem Rechner dauert der Login in KDE mit SDDM ca 60sec.
In der .xsession_error hängt der Login an dieser Stelle
dbus-update-activation-environment: setting _=/usr/bin/dbus-update-activation-environment
Hat jemand eine Idee, woran das liegen könnte?
Den Nutzer hatte ich schon komplett gelöscht und neu angelegt. Bei anderen Nutzern ist das Phänomen das Gleiche.
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Vorweg, ich verwende sddm nicht.
Aber nachdem deinen Beitrag keiner beantwortet hat, wäre eine Idee, doch einfach einmal in die globale Konfigurationsdatei (wahrscheinlich unter /etc/... ) zu schauen und nach dem Schlüsselwort "time" oä zu suchen.
Weiterhin wäre es schön, wenn du alle relevanten Logfiles und Konfigurationsdateien zu sddm hier im Forum postest.
Bitte längere (ab 6 Zeilen ) Dateiausgaben nach NoPoste packen und hier im Thread verlinken.
Du wirst sehen, mit etwas Zuarbeit wird die Hilfsbereitschaft der Forenteilnehmer wesentlich gesteigert.
Aber nachdem deinen Beitrag keiner beantwortet hat, wäre eine Idee, doch einfach einmal in die globale Konfigurationsdatei (wahrscheinlich unter /etc/... ) zu schauen und nach dem Schlüsselwort "time" oä zu suchen.
Weiterhin wäre es schön, wenn du alle relevanten Logfiles und Konfigurationsdateien zu sddm hier im Forum postest.
Bitte längere (ab 6 Zeilen ) Dateiausgaben nach NoPoste packen und hier im Thread verlinken.
Du wirst sehen, mit etwas Zuarbeit wird die Hilfsbereitschaft der Forenteilnehmer wesentlich gesteigert.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Hallo,
ich habe das Problem eigentlich schon aufgegeben.
Ein Googeln brachte meistens eine Neuinstallation. Dazu habe ich ehrlich gesagt keine Lust.
Die Fehler traten, sowiet ich mich erinnere, bei anderen Distris auf (Ubuntu). Ist also kein Debian-Problem, scheint an KDE zu liegen.
So, ich habe mal den sddm.log gelöscht und geschaut, ob danach etwas Neues rein geschrieben wurde. Das war nicht der Fall.
Die ".xsession-errors" zeigt aber an, was sddm gerade versucht zu tun und wo es hängt.
Hier der Link zur ".xsession-errors" aus dem home Verzeichnis zum Login:
pastebin/?mode=view&s=40926
Der Hänger ist genau hier:
Falls jemand eine Idee hat, nur zu. Ansonsten warte ich auf das nächste stable release "bullseye".
ich habe das Problem eigentlich schon aufgegeben.
Ein Googeln brachte meistens eine Neuinstallation. Dazu habe ich ehrlich gesagt keine Lust.
Die Fehler traten, sowiet ich mich erinnere, bei anderen Distris auf (Ubuntu). Ist also kein Debian-Problem, scheint an KDE zu liegen.
So, ich habe mal den sddm.log gelöscht und geschaut, ob danach etwas Neues rein geschrieben wurde. Das war nicht der Fall.
Die ".xsession-errors" zeigt aber an, was sddm gerade versucht zu tun und wo es hängt.
Hier der Link zur ".xsession-errors" aus dem home Verzeichnis zum Login:
pastebin/?mode=view&s=40926
Der Hänger ist genau hier:
Code: Alles auswählen
dbus-update-activation-environment: setting _=/usr/bin/dbus-update-activation-environment
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Na, das kann aber noch dauern...mikelm hat geschrieben:25.11.2019 19:37:12Ansonsten warte ich auf das nächste stable release "bullseye".
Du könntest aber testweise das Paket "lightdm" installieren, um zu sehen, ob der Fehler in KDE bzw. SDDM zu suchen ist.
Wenn ich mich recht erinnere, wirst Du bei der Installation gefragt, welcher Display-Manager genutzt werden soll, kann also nichts passieren.
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Das Paket dbus ist aber installiert?mikelm hat geschrieben:25.11.2019 19:37:12Code: Alles auswählen
dbus-update-activation-environment: setting _=/usr/bin/dbus-update-activation-environment
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Ich könnte das falsch in Erinnerung haben, aber in der Vergangenheit gab es diese Beschwerden über Boot- und Loginverzögerungen doch auch schon mal. In solchen Fällen war doch die Abhilfe, haveged zu installieren.
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Ich habe zwar Testing, aber ähnliche Probleme.
Daran liegt es - zumindest bei mir - nicht. Ist installiert.
Es gab mal eine Zeit, (bis vor ca. 2 Monaten) da startete KDE wie eine Biene (M.2 SSD / SATA)
Aber leider ist es nicht mehr so. Jetzt hängt der Bootvorgang bei diesem dusseligen Label (drei Punkte - Pfeil) um ziemlich genau 30 Sekunden,
bevor der Desktop geruht zu erscheinen.
Aber:
Code: Alles auswählen
systemd-analyze
Startup finished in 2.564s (kernel) + 8.722s (userspace) = 11.287s
graphical.target reached after 8.706s in userspace
Code: Alles auswählen
Nov 26 12:11:25 debiankde systemd[1]: Mounted FUSE Control File System.
Nov 26 12:11:28 debiankde dbus-daemon[1639]: [session uid=1000 pid=1639] Activating service name='org.gnome.GConf' requested by ':1.52' (uid=1000 pid=3861 comm="/usr/bin/waterfox ")
Nov 26 12:11:29 debiankde dbus-daemon[1639]: [session uid=1000 pid=1639] Successfully activated service 'org.gnome.GConf'
Nov 26 12:12:45 debiankde systemd[1]: Started Run anacron jobs.
Nov 26 12:12:45 debiankde anacron[5797]: Anacron 2.3 started on 2019-11-26
Nov 26 12:12:45 debiankde anacron[5797]: Normal exit (0 jobs run)
Nov 26 12:12:45 debiankde systemd[1]: anacron.service: Succeeded.
Nov 26 12:17:01 debiankde CRON[11323]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 26 12:17:01 debiankde CRON[11331]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 26 12:17:01 debiankde CRON[11323]: pam_unix(cron:session): session closed for user root
Werde jetzt mal lightdm installieren. Mal sehen.
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
So lightdm installiert
Nach dem er mich erstmal auf eine leere LXQT- Session geschickt hatte Folgende Beobachtung:
Autologin:---> Dasselbe Drama
kein Autologin -----> Eins zwei drei, die Session samt Oberfläche erscheint ohne großartige Verzögerung.
Da werde mal jemand schlau draus
Nach dem er mich erstmal auf eine leere LXQT- Session geschickt hatte Folgende Beobachtung:
Autologin:---> Dasselbe Drama
kein Autologin -----> Eins zwei drei, die Session samt Oberfläche erscheint ohne großartige Verzögerung.
Da werde mal jemand schlau draus
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
So - Lighdm wieder rausgeschmissen.
Es ist auch bei sddm so, das der Unterschied Autologin bzw. kein Autologin ist.
Bei beiden Display- Manager das Gleiche.
Oberfläche erscheint ohne Autologin in 3 -5 Sekunden nach der PW-Eingabe (also dieses Logo-> dann Desktop)
Mit Autologin dauert es ca.30 Sekunden .( Logo-> dann Desktop)
hmmmmmmmmmm
Es ist auch bei sddm so, das der Unterschied Autologin bzw. kein Autologin ist.
Bei beiden Display- Manager das Gleiche.
Oberfläche erscheint ohne Autologin in 3 -5 Sekunden nach der PW-Eingabe (also dieses Logo-> dann Desktop)
Mit Autologin dauert es ca.30 Sekunden .( Logo-> dann Desktop)
hmmmmmmmmmm
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
In den Systemsettings/Arbeitsbereich-Design/Startbildschirm 'Keiner' einstellen und es flutscht wieder mit dem Autologin...zumindest bei mir unter sid.willy4711 hat geschrieben:26.11.2019 15:54:01Es ist auch bei sddm so, das der Unterschied Autologin bzw. kein Autologin ist.
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Danke für den Tipp. Dabei habe ich festgestellt, das dort ein ziemliches Durcheinander herrschte Nur leere Symbole ,"Keiner" war nicht vorhanden.dillo hat geschrieben:26.11.2019 22:06:52In den Systemsettings/Arbeitsbereich-Design/Startbildschirm 'Keiner' einstellen und es flutscht wieder mit dem Autologin...zumindest bei mir unter sid.
Hab dann das ganze Plymouth- Zeugs noch mal reinstalliert, und gesehen,das es da noch ein plymouth-x11 gab, was gar nicht installiert war.
Jetzt läuft es, auch mit Bildchen
Re: Verzögerter SDDM Login in KDE nach Update auf Buster
Danke für die Tipps, hat aber leider alles nichts gebracht. dbus und haveged waren installiert, plymouth-x11 hatte mit dem Problem nichts zu tun.
Da warte ich auf den Nachfolger von buster, der Rechner ist sowieso meistens im Standby, da tritt das Problem nicht auf.
Da warte ich auf den Nachfolger von buster, der Rechner ist sowieso meistens im Standby, da tritt das Problem nicht auf.