Debian 12 (stable, Bookworm) + KDE + Wayland: Nach Updates mehrerer *deb-Pakete friert Mauszeiger ein

[prox]

Gestern wurden auf meinen Rechner Updates für das darauf installierte Debian 12 (stable, Bookworm) angeboten. Diese Updates hatte ich gestern anschließend in mein System eingespielt.

Nach dem danach erfolgten Neustart meines Rechners und dem Login in KDE mit Wayland als Display-Server-Protokoll beobachtete ich folgendes Verhalten:

Variante a):

Nach jeweils einem kurzem Nichtgebrauch der Maus lässt sich der Mauszeiger nur mit Nachdruck wieder aktivieren, durch kräftiges Rütteln an der kabelgebundenen USB-Maus.

Variante b):

Oder der Mauszeiger friert komplett ein.

In einem solchen Fall hilft es nicht, den Stecker der kabelgebundene Maus aus dem USB-Slot am Laptop zu entfernen und wieder dort einzustecken.

Das Verhalten (Variante a + b) kann nur wie folgt beseitigt werden:

- Reboot des Systems und Login in KDE, dabei als Startoption "Plasma (X11)" im SDDM ausgewählt.

Zu meinem System:

a) Laut der Datei /etc/debian_version ist aktuell Debian in Version 12.6 auf meinem Rechner installiert.

b) Gestern wurden laut der Datei /var/log/apt/history.log folgende Debian-Pakete im Rahmen des gestrigen Update-Prozesses auf meinem Laptop installiert:

Start-Date: 2024-08-05 19:33:54
Commandline: apt-get upgrade
Upgrade: liblibreoffice-java:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-calc:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), uno-libs-private:amd64 (4:7.4
.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-base-core:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-core:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), li
breoffice-common:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), ure:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-draw:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+d
eb12u4), libuno-purpenvhelpergcc3-3:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libuno-cppu3:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-impress:amd64
(4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-l10n-de:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libuno-cppuhelpergcc3-3:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+d
eb12u4), fonts-opensymbol:amd64 (4:102.12+LibO7.4.7-1+deb12u3, 4:102.12+LibO7.4.7-1+deb12u4), libunoloader-java:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffi
ce-style-colibre:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-writer:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-plasma:amd64 (4:7.4.7-1+deb
12u3, 4:7.4.7-1+deb12u4), libuno-salhelpergcc3-3:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-style-breeze:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), l
ibreoffice-help-de:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-help-common:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), python3-uno:amd64 (4:7.4.7-1+deb
12u3, 4:7.4.7-1+deb12u4), libuno-sal3:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-math:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), ure-java:amd64 (4:7.
4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-java-common:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-help-en-us:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb
12u4), libreoffice-kf5:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4), libreoffice-qt5:amd64 (4:7.4.7-1+deb12u3, 4:7.4.7-1+deb12u4)
End-Date: 2024-08-05 19:36:20

Installiertes xwayland-Paket:

Code: Alles auswählen

root@xxx:/var/log/apt# apt list xwayland
Auflistung… Fertig
xwayland/stable,now 2:22.1.9-1 amd64  [Installiert,automatisch]

In der oben genannten Liste der Pakete, die gestern auf meinem Rechner aktualisiert worden sind, ist übrigens keine Paketbezeichnung mit der Zeichenkette *wayland* enthalten.

Bisherige Analyse des Verhaltens:

Im Log von journalctl lassen sich über das oben beschriebene Verhalten folgende Zeilen mehrfach finden, so lange KDE unter Einsatz von Wayland läuft:

Code: Alles auswählen

Aug 05 22:21:44 punk kernel: usb 2-1.3: reset low-speed USB device number 6 using ehci-pci
Aug 05 22:21:46 punk kernel: usb 2-1.3: device not accepting address 6, error -32

Zum Fehlercode "-32" habe ich folgende Information ermittelt:

Code: Alles auswählen

root@xxx:~# errno 32
EPIPE 32 Datenübergabe unterbrochen (broken pipe)

Hat jemand anders dieses Verhalten auch beobachten können? Irgendeine Idee, was dagegen unternommen werden könnte?

Falls gewünscht, kann ich den Rest der von mir gestern in eine Textdatei extrahierten journalctl-Informationen hier in diesen Thread nachträglich einstellen.

[mat6937]

Nach jeweils einem kurzem Nichtgebrauch der Maus lässt sich der Mauszeiger nur mit Nachdruck wieder aktivieren, durch kräftiges Rütteln an der kabelgebundenen USB-Maus.

Variante b):

Oder der Mauszeiger friert komplett ein.

Starte mal top im Terminal/Kommandozeile und warte bis der Mauszeiger nicht mehr benutzt werden kann (besser bis er einfriert).
Zeigt bzw. aktuallisiert top danach noch und wenn ja, gibt es einen oder mehrere Prozesse mit hohem CPU-/Speicher-Verbrauch?

[prox]

Hi mat6937,

Guter Hinweis, vielen Dank. Ich hatte auch diese Sache mit der 100%igen CPU-Auslastung in Verbindung mit Wayland wohl hier in diesem Forum gestern gesehen.

Ich werde das wohl morgen mal austesten.

Nachtrag: Ich hatte vorhin auch mal in der Debian Bug Database zu Wayland-Bugs für das Paket xwayland geschaut: Das von mir berichtete Verhalten ist zwar in dieser Form so noch nicht dort dokumentiert, aber es gibt dort wohl 3 noch offene Bugs, in deren Überschriften der Begriff "mouse" vorkommt.

[prox]

Hi mat6937,

ich habe gerade Deinen Hinweis umgesetzt:

1. Rechner neugestartet, im SDDM an KDE mit der Startoption "Plasma (Wayland)" angemeldet.

2. Während des KDE-Startvorgangs bin ich mittels STRG+ALT+F2 auf die tty2-Konsole gewechselt, habe mich dort als Benutzer root angemeldet.

3. In der tty2-Konsole das Programm htop gestartet.

Die beiden obersten Balken in htop (stellen die beiden Kerne in der CPU meines Laptops dar) sprangen sofort auf 100% Auslastung hoch. Nach ein paar Sekunden gingen die beiden Balken aber wieder runter auf eine CPU-Auslastung von vielleicht 10-15%.

4. Mittels STRG+ALT+F7 bin ich auf die GUI von KDE zurückgewechselt:

In der GUI wurde, und das ist mir schon vorgestern im Zusammenhang mit dem hier beschriebenen Verhalten aufgefallen, die GUI des SDDM angezeigt, aber nicht die KDE-GUI, und zwar mit meinem bereits eingegebenen Passwort (dargestellt in Form runder Punkte) für mein Benutzerkonto, wobei das Passwortfeld als inaktiv dargestellt wurde, eine erneute Passworteingabe war deswegen nicht mehr möglich. Die Darstellung der GUI hing also bei der Anzeige des SDDM fest, die GUI von KDE wurde also nicht angezeigt.

Auch deswegen musste ich den Rechner auf der tty2-Konsole in den Reboot schicken und danach KDE wieder mit der Option "Plasma (X11) starten, damit ich diesen Beitrag hier in diesem Thread auch schreiben konnte.

[mat6937]

2. Während des KDE-Startvorgangs bin ich mittels STRG+ALT+F2 auf die tty2-Konsole gewechselt,

Versuch mal mit der Konsole (terminal emulator), d. h. ohne STRG+ALT+F2 und als normaler user (nicht root).

[towo]

Die Darstellung der GUI hing also bei der Anzeige des SDDM fest, die GUI von KDE wurde also nicht angezeigt.

Unfug, eine Wayland-Session läuft nicht auf TTY7!

[prox]

Die Darstellung der GUI hing also bei der Anzeige des SDDM fest, die GUI von KDE wurde also nicht angezeigt.

Unfug, eine Wayland-Session läuft nicht auf TTY7!

Wie jetzt? Ich meinte doch die GUI von KDE. Von Wayland habe ich doch in diesem Zusammenhang gar nicht geredet.

Fakt ist, wenn Du den Shortcut STRG+ALT+F7 von einer TTY != 7 aus betätigst, kommst Du zur grafischen Oberfläche, in diesem Fall zur GUI von KDE.

[towo]

Fakt ist, wenn Du den Shortcut STRG+ALT+F7 von einer TTY != 7 aus betätigst, kommst Du zur grafischen Oberfläche, in diesem Fall zur GUI von KDE.

Nein! Nicht wenn KDE auf Wayland läuft!

1. Rechner neugestartet, im SDDM an KDE mit der Startoption "Plasma (Wayland)" angemeldet.

[prox]

@towo, vielen Dank für Deine ausführliche Erklärung.

Kannst Du Dir vielleicht vorstellen, dass ich mich mit Wayland nicht wirklich auskenne?

@mat6937, ich bin gerade unter Wayland in KDE angemeldet. In einer virtuellen Konsole läuft gerade htop unter einen normalen User-Account. Bisher läuft KDE stabil, die Maus ist bisher nicht eingefroren. Und die CPU-Anzeige in htop ist auch im niedrigeren %-Prozentbereich, maximal 44%, jedenfalls bisher.

Ich melde mich später noch mal.

[prox]

Update:

Aktuell läuft KDE + Wayland stabil, die Maus zickt nicht rum, der Bildschirm friert nicht ein. Das ist jetzt das zweite Mal heute, dass ich längere Zeit unter KDE + Wayland ohne das von mir gestern berichtete Verhalten mit Debian 12 arbeiten kann.

Ist das Verhalten einfach "verschwunden"? Mal schauen. Ticket bleibt bis auf Weiteres offen

[prox]

Update:

Status immer noch so:

Aktuell läuft KDE + Wayland stabil, die Maus zickt nicht rum, der Bildschirm friert nicht ein

Aber:

Wechsle ich von der TTY7 mit darin angezeigter KDE-GUI nach dem Login in KDE, das unter Wayland läuft, auf die TTY2, logge mich dort als root ein und wechsle dann wieder zurück zur TTY7, dann wie bisher weiterhin folgendes Verhalten:

In der GUI wurde, und das ist mir schon vorgestern im Zusammenhang mit dem hier beschriebenen Verhalten aufgefallen, die GUI des SDDM angezeigt, aber nicht die KDE-GUI, und zwar mit meinem bereits eingegebenen Passwort (dargestellt in Form runder Punkte) für mein Benutzerkonto, wobei das Passwortfeld als inaktiv dargestellt wurde, eine erneute Passworteingabe war deswegen nicht mehr möglich. Die Darstellung der GUI hing also bei der Anzeige des SDDM fest, die GUI von KDE wurde also nicht angezeigt.

Danach musste ich den Rechner neu starten, um mich wieder erfolgreich in die KDE-GUI einloggen zu können.

In den Protokollinformationen von journalctl finde ich zu diesem Verhalten nichts Aussagekräftiges.

[mat6937]

Danach musste ich den Rechner neu starten, ...

Wie sind vor dem Neustart des Rechners, die Ausgaben von:

Code: Alles auswählen

free
top -n 1 -b|grep "load average" -A 20

?

[towo]

Wechsle ich von der TTY7 mit darin angezeigter KDE-GUI nach dem Login in KDE, das unter Wayland läuft, auf die TTY2, logge mich dort als root ein und wechsle dann wieder zurück zur TTY7, dann wie bisher weiterhin folgendes Verhalten:

Ich habe es dir doch schonmal geschrieben, auf tty7 läuft ein X-Server (und dort sddm)!
Die Wayland Session läuft vermutlich auf tty1.

[prox]

Ich habe es dir doch schonmal geschrieben, auf tty7 läuft ein X-Server (und dort sddm)!
Die Wayland Session läuft vermutlich auf tty1.

Nö, eine derartige Anstrengung, mir das in dieser Form zu erklären, hattest Du bisher nicht mir gegenüber gemacht. Aber vielleicht hattest Du ja Deine bisherigen Beiträge hier im Thread editiert und diese Infos dort nachgetragen. Ich schaue deswegen aber jetzt nicht dort nach.

[prox]

Wie sind vor dem Neustart des Rechners, die Ausgaben von:

Code: Alles auswählen

free
top -n 1 -b|grep "load average" -A 20

?

Hier die Ausgabe des ersten Befehls:

Code: Alles auswählen

              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:    3898036     1852556     1271840       92240     1102944     2045480
Swap:        7812092      254988     7557104

Die Ausgabe des zweiten Befehls:

Code: Alles auswählen

top - 06:29:42 up  1:40,  2 users,  load average: 0,81, 1,45, 1,32
Tasks: 179 total,   1 running, 178 sleeping,   0 stopped,   0 zombie
%CPU(s):  4,5 us, 13,6 sy,  0,0 ni, 31,8 id, 50,0 wa,  0,0 hi,  0,0 si,  0,0 st 
MiB Spch:   3806,7 total,   1249,9 free,   1800,9 used,   1077,4 buff/cache     
MiB Swap:   7629,0 total,   7380,0 free,    249,0 used.   2005,8 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   5782 root      20   0   11704   5204   3288 R   5,9   0,1   0:00.03 top
      1 root      20   0  102536  11940   8476 S   0,0   0,3   0:02.48 systemd
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kthreadd
      3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
      4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par+
      5 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 slub_fl+
      6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 netns
     10 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_perc+
     11 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_tas+
     12 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_tas+
     13 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_tas+
     14 root      20   0       0      0      0 S   0,0   0,0   0:00.69 ksoftir+
     15 root      20   0       0      0      0 I   0,0   0,0   0:02.19 rcu_pre+
     16 root      rt   0       0      0      0 S   0,0   0,0   0:00.04 migrati+

Also kein Anzeichen dafür, dass die CPU in der von mir beschriebenen Situation zu 100% in Anspruch genommen worden ist.

[mat6937]

Wechsle ich von der TTY7 mit darin angezeigter KDE-GUI nach dem Login in KDE, das unter Wayland läuft, auf die TTY2, logge mich dort als root ein und wechsle dann wieder zurück zur TTY7, dann wie bisher weiterhin folgendes Verhalten:

In der GUI wurde, und das ist mir schon vorgestern im Zusammenhang mit dem hier beschriebenen Verhalten aufgefallen, die GUI des SDDM angezeigt, aber nicht die KDE-GUI, und zwar mit meinem bereits eingegebenen Passwort (dargestellt in Form runder Punkte) für mein Benutzerkonto, wobei das Passwortfeld als inaktiv dargestellt wurde, eine erneute Passworteingabe war deswegen nicht mehr möglich. Die Darstellung der GUI hing also bei der Anzeige des SDDM fest, die GUI von KDE wurde also nicht angezeigt.

Danach musste ich den Rechner neu starten, um mich wieder erfolgreich in die KDE-GUI einloggen zu können.

Hattest Du dieses Verhalten auch _vor dem Update_?

Wenn Du unter bookworm mit 4 GB-RAM, KDE benutzt, solltest Du m. E. die Speicherbenutzung (RAM, SWAP) optimieren.

[prox]

Hattest Du dieses Verhalten auch _vor dem Update_?

Nein, natürlich nicht. Denn gerade deswegen hatte ich ja in meinem ersten Beitrag hier in diesen Threat auf die besagten Paket-Updates hingewiesen und deren Bezeichnungen deswegen hier auch aufgeführt.

Wenn Du unter bookworm mit 4 GB-RAM, KDE benutzt, solltest Du m. E. die Speicherbenutzung (RAM, SWAP) optimieren.

Keine Sorgen, das ist schon so weit wie möglich von mir optimiert worden. Mehr (also weniger benutzter RAM) ist nicht drin, jedenfalls nicht unter Verwendung von KDE.

[mat6937]

Keine Sorgen, das ist schon so weit wie möglich von mir optimiert worden.

Wie hast Du das gemacht bzw. optimiert?

Mehr (also weniger benutzter RAM) ist nicht drin, jedenfalls nicht unter Verwendung von KDE.

Das meinte ich ja auch nicht. Es soll nicht weniger RAM benutzt werden bzw. bookworm benutzt eh mehr RAM als bullseye.
Es geht darum, dass in Bezug auf die RAM-Nutzung bestimmte relevante Prozesse nicht gekillt werden bzw. ungünstig priorisiert werden und nicht gedrosselt werden.

[prox]

Das meinte ich ja auch nicht. Es soll nicht weniger RAM benutzt werden bzw. bookworm benutzt eh mehr RAM als bullseye.
Es geht darum, dass in Bezug auf die RAM-Nutzung bestimmte relevante Prozesse nicht gekillt werden bzw. ungünstig priorisiert werden und nicht gedrosselt werden.

Hat denn die Art und Weise, wie die Prozesse während des Verhaltens (hier: SDDM-Anmeldebildschirm wird angezeigt, kann aber nicht benutzt werden, ist de facto eingefroren) untereinander priorisiert werden, etwas mit diesem Verhalten zu tun?

Ich kann das jedenfalls so erst einmal nicht erkennen.

[towo]

Wi eoft muss man es denn noch sagen?
Dein sddm läuft auf Xorg, und daraus hast Du eine Plasma-Wayland session gestartet, solange diese nicht beendet wird, ist das verhalten von sddm ganz normal.
Du wirst auf tty7 auch nie deine Plasma-Session sehen, weil da eben ein Xserver läuft (mit sddm).

[mat6937]

Wi eoft muss man es denn noch sagen?

Hast Du auch eine Lösung/Empfehlung für den TE?

[towo]

Aktuell läuft KDE + Wayland stabil, die Maus zickt nicht rum, der Bildschirm friert nicht ein

Der TE hat kein Problem, zumindest sehe ich keins. Zu was soll ich also eine Lösung posten?

[prox]

Aktuell läuft KDE + Wayland stabil, die Maus zickt nicht rum, der Bildschirm friert nicht ein

Der TE hat kein Problem, zumindest sehe ich keins. Zu was soll ich also eine Lösung posten?

TTY7 ist nicht nutzbar, da dort der Anmeldeschirm des SDDM mit dem bereits von mir eingegebenen Passwort angezeigt wird, wobei das Eingabefeld für das Passwort inaktiv dargestellt wird - das entspricht dem Zustand, nachdem das (richtige) Passwort in das Passwortfeld im SDDM eingegeben worden ist und KDE deswegen im Begriff ist, den KDE-Desktop für den erfolgreich an KDE angemeldeten User aufzubauen - was aber nicht passiert:

TTY7 hängt bei der Darstellung von SDDM mit dem (richtigen) Passwort des jeweiligen Users. Und dies auch noch, nachdem mir der KDE-Desktop bereits erfolgeich angezeigt worden war, bevor ich aus der KDE-Desktopumgebung auf TTY2 gewechselt bin. Und von dort zurück auf TTY7 - was zu dem hier beschriebenen Verhalten führt.

Und deswegen kann ich diesen Zustand vorerst nur dadurch beheben, indem ich wieder auf TTY2 wechsle und dort einen Reboot des Rechners initiiere.

Noch genauer kann ich dieses Verhalten bzgl. der Darstellung des quasi festgefrorenen SDDM-Anmeldeschirms auf TTY7 nicht beschreiben.

[mat6937]

TTY7 ist nicht nutzbar, da dort der Anmeldeschirm des SDDM mit dem bereits von mir eingegebenen Passwort angezeigt wird, wobei das Eingabefeld für das Passwort inaktiv dargestellt wird - das entspricht dem Zustand, nachdem das (richtige) Passwort in das Passwortfeld im SDDM eingegeben worden ist und KDE deswegen im Begriff ist, den KDE-Desktop für den erfolgreich an KDE angemeldeten User aufzubauen - was aber nicht passiert:

..., indem ich wieder auf TTY2 wechsle ...

Wie sind nach dem wechseln auf TTY2, die Ausgaben von:

Code: Alles auswählen

pgrep sddm
systemctl status sddm
systemctl cat sddm
choom -p $(pgrep -o sddm)
choom -p $(pgrep -n sddm)

?

[prox]

Hi mat6937,

hier die Ausgaben der von Dir genannten Kommandos (bin dazu von der KDE-Oberfläche zu TTY2 gewechselt, dann zurück zu TTY7 (das Verhalten tritt jetzt auf), dann wieder zu TTY2 und habe dort dann die von Dir genannten 5 Befehle ausgeführt:

# pgrep sddm:

Code: Alles auswählen

668
849

# systemctl status sddm:

Code: Alles auswählen

sddm.service - Simple Desktop Display Manager
     Loaded: loaded (/lib/systemd/system/sddm.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-08-11 12:29:49 CEST; 11min ago
       Docs: man:sddm(1)
             man:sddm.conf(5)
   Main PID: 668 (sddm)
      Tasks: 7 (limit: 4488)
     Memory: 112.9M
        CPU: 1.328s
     CGroup: /system.slice/sddm.service
             ├─668 /usr/bin/sddm
             └─726 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{cf71031f-7649-4d90-93f1-cf4d274f9aac} -background none -noreset -displayfd 17 -seat seat0 vt7

Aug 11 12:30:23 punk sddm-helper[849]: gkr-pam: unable to locate daemon control file
Aug 11 12:30:23 punk sddm-helper[849]: gkr-pam: stashed password to try later in open session
Aug 11 12:30:23 punk sddm-helper[849]: [PAM] returning.
Aug 11 12:30:23 punk sddm-helper[849]: pam_kwallet5(sddm:auth): pam_kwallet5: pam_sm_authenticate
Aug 11 12:30:23 punk sddm[668]: Authenticated successfully
Aug 11 12:30:23 punk sddm-helper[849]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Aug 11 12:30:23 punk sddm-helper[849]: pam_unix(sddm:session): session opened for user xxx(uid=1000) by (uid=0)
Aug 11 12:30:24 punk sddm[668]: Auth: sddm-helper exited successfully
Aug 11 12:30:24 punk sddm[668]: Greeter stopped.
Aug 11 12:30:25 punk sddm[668]: Session started

# systemctl cat sddm:

Code: Alles auswählen

# /lib/systemd/system/sddm.service
[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
# Change this if you want to start sddm in a different tty
Conflicts=getty@tty1.service getty@tty7.service
After=getty@tty1.service getty@tty7.service

After=systemd-user-sessions.service systemd-logind.service
# Workaround entropy starvation
After=haveged.service

# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service

[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStart=/usr/bin/sddm
Restart=always
RestartSec=1s
EnvironmentFile=-/etc/default/locale

[Install]
Alias=display-manager.service

# choom -p $(pgrep -o sddm):

Code: Alles auswählen

pid 668's current OOM score: 667
pid 668's current OOM score adjust value: 0

# choom -p $(pgrep -n sddm):

Code: Alles auswählen

pid 849's current OOM score: 667
pid 849's current OOM score adjust value: 0