# KDE macht mit jedem DM Ärger.

## Klaus Meier

Also erst mal eins vorweg, dieses KDE war eine Spielinstallation, wo ich einfach mal alles ohne Rücksicht auf Verluste ausprobiert habe. Was ich noch dazu sagen möchte, ich nutze systemd und Wlan über den networkmanager.

- Das Problem mit dem kdm hatten wir ja schon, lies sich mit der Installation von lightdm beheben.

- Dann habe ich mir da lx_qt und den sddm drauf getan. Das Ergebnis: Mit dem sddm ließen sich bei lx_qt keine Anwendungen aus dem Menü mehr starten, mit dem lightdm schon. sddm und lx_qt wieder gelöscht.

- KDE gefällt mir sehr gut, nur ist okular viel langsamer als evince. Also evince unter KDE installiert. Ergebnis: Es lassen sich keine Anwendungen mehr über das Menü starten.

Da dachte ich, ich hab mir das ganze kaputt installiert, also einfach einmal neu. Ergebnis:

- Erst mal kdebase-meta gebaut und mit lightdm gestartet. Läuft alles ohne Probleme.

Dann das volle kde-meta und noch den sddm. Ergebnis:

- Sowohl bei kdm, lightdm und sddm startet KDE nicht durch. Es erscheinen ja diese Symbole auf dem Bildschirm. Nach dem ersten Symbol (Festplatte) bin ich dann wieder beim Login. Beim zweiten Versuch klappt es.

- Bei kdm und lightdm kann ich dann keine Anwendung mehr aus dem Menü starten. Netzwerk ok.

- Bei sddm ist das Netzwerk im nm_applet deaktiviert und lässt sich nicht aktivieren. Anwendungen lassen sich aus dem Menü starten.

Und das ist reproduzierbar, wenn man zwischen den DMs wechselt. Es läuft gerade ein emerge -e world, aber ich glaube nicht, dass das etwas bringt.

So wie es aussieht, gibt es dann Probleme, wenn ich den sddm dazu installiere. Hat da jemand Erfahrungen mit? Ich würde ihn gerne nutzen, weil er sehr viel schneller startet als der lightdm.

Deshalb die Fragen, weil ich  das jetzt nicht an mehreren Neuinstallationen austesten möchte: Macht der sddm an sich Probleme? Oder nur in Verbindung mit dem lightdm? Kann es sein, dass er eine Installation schrottet, was auch nicht dadurch zu beheben ist, dass man ihn wieder deinstalliert?

Ach so, den Cache unter /var/tmp und die Konfigurationsdateien in /home habe ich gelöscht.Last edited by Klaus Meier on Sat Jul 26, 2014 6:09 am; edited 2 times in total

----------

## Yamakuzure

Ich habe sddm erst ein mal ausporbiert, und das hat auf Anhieb funktioniert. Bei dir scheint etwas ganz Anderes schief zu sein.

Gibt es Auffälligkeiten in dmesg, /var/log/messages und/order /var/log/Xorg.0.log ?

----------

## Klaus Meier

Ich hab das ganze mal neu installiert und da geht inzwischen genau gar nichts. Also jetzt eine Neuinstallation, bei der eigentlich alles sauber sein sollte. Ich sehe da inzwischen nur noch Systemd, zu dem man ja dank Gnome gezwungen wurde und was ich dann auch für das KDE übernommen habe, damit es so halbwegs einheitlich ist.

Werde es noch mal ohne Systemd testen.

----------

## py-ro

Also systemd + kdm + kde tun hier auf diversen Systemen in diversen Versionen problemfrei, auch auf dem Notebook erst am WE installiert.

----------

## Klaus Meier

testing oder stable? Bei mir lief das auch mal alles ohne Probleme und jetzt kackt da immer mehr ab. Erst war es der kdm und jetzt geht irgendwie gar nichts mehr.

----------

## mv

Erste Frage bei so etwas: Ist dbus gestartet: system-dbus, session-dbus, ...?

Wenn es an dbus nicht liegt, ist der nächste Kandidat pam (der Hauptgrund, weshalb ich weder lightdm noch sddm nutze: pam ist dort nicht optional.)

Es könnte sein, dass Dir sddm eine kaputte pam-Regel installiert, die kde nicht mag; vom Hörensagen ist pam-base in gentoo ohnehin ziemlich verquer (so dass Gerüchten zufolge wenigstens ein Entwickler deswegen abgesprungen sein soll...): da ich selbst pam nicht nutze, kann ich da aber wenig Konstruktives zu sagen.

----------

## Klaus Meier

dbus ist bei systemd doch immer an, man muss es doch nicht manuell aktivieren. Und es war ja auch systemd, durch welches ich kdm nicht mehr nutzen konnte. Ich teste jetzt das ganze noch mal alles ganz normal ohne lightdm und sddm mit sysVinit.

----------

## py-ro

kdm funktioniert sowohl in stable wie auch in unstable aber eigentlich problemfrei mit systemd

----------

## mv

 *Klaus Meier wrote:*   

> dbus ist bei systemd doch immer an, man muss es doch nicht manuell aktivieren

 

Stimmt, Du schriebst ja, dass Du Systemd benutzt. Dass systemd den session-dbus ebenfalls automatisch startet, glaube ich aber nicht - dafür müsste eigentlich der login-manager zuständig sein (zumindest, um dies an systemd zu signalisieren).

----------

## Klaus Meier

Ich probiere es jetzt mal mit SysVinit. Mach dann vor dem ersten Start ein Backup, dann kann ich damit etwas rumspielen.

Tja, wie gesagt, mit SysVinit ging das auch alles super. Einige Zeit dann mit Systemd, dann wollte der kdm nicht mehr, jetzt geht entweder Netz oder Anwendung starten, da bekommt man doch die Krätze. Und nun ist ja heute auch noch Version 4.13.2 raus gekommen. Da warte ich noch, bis die im Portage ist, so kann ich morgen alles noch mal bauen...

----------

## Klaus Meier

Ok, so wie es aussieht, funktioniert es jetzt erst mal wieder. Es lag an systemd. Mit sysvinit ist alles OK. Sehr komisch, da es ziemlich lange ohne Probleme mit systemd lief.

----------

## Klaus Meier

Ich wollte nochmal nachfragen, ob zu diesem Problem jemand eine Idee hat. Also es geht jetzt um systemd, welches ich gerne nutzen würde. Ich habe in Bezug auf dieses Thema noch etwas rumprobiert und kann jetzt folgendes sagen:

- Mit dem sddm wird der Networkmanager nicht gestartet. Ist genauso, wie ohne systemctl enable NetworkManager. Anwendungen funktionieren, wie lange habe ich nicht getestet. Ob weiter Dienste gestartet werden habe ich auch nicht geprüft.

- Mit dem lightdm geht erst mal alles prima. Für ein paar Stunden. Dann tritt mitten im Betrieb der Fehler auf, dass sich keine Anwendungen aus dem Menü mehr starten lassen. Wenn ich in KMail auf einen Link klicke, startet auch kein Browser. Laufende Anwendungen lassen sich aber weiter bedienen.

Dieses Problem ist zeitabhängig. Wenn der Rechner zu diesem Zeitpunkt nicht läuft, dann tritt er halt erst beim nächsten Neustart auf. Und ich dachte deshalb, es läge an einer Änderung, die ich vor diesem Neustart vorgenommen hatte.

Wegen der Zeit, ich bin vor einiger Zeit auf cronie umgestiegen wegen anacron. Kann es eventuell daran liegen?

----------

## mv

 *Klaus Meier wrote:*   

> Für ein paar Stunden. Dann tritt mitten im Betrieb der Fehler auf

 

Der erste Verdacht ist, dass da etwas die tmp-files aufräumt und dabei fehlerhafterweise auch sockets mitnimmt, deren Zeitstempel zu alt ist.

Du kannst mal schauen, ob irgendein verdächtiger "D"- oder "d"-Eintrag in /etc/tempfiles.d oder /usr/lib/tempfiles.d steht.

Die andere Möglichkeit wäre ein fehlkonfigurierter Aufruf von "tmpwatch" (falls Du das installiert hast), oder eben eine Clean-Funktion von cronie/anacron selbst (ich benutze beides nicht, kann also nichts dazu sagen).

Wenn Du schon systemd benutzt, kannst Du Dir auch überlegen, ob Du (neue Version von systemd vorausgesetzt) überhaupt cronie/anacron haben wlilst: Es gibt ja auch die Möglichkeit von systemd-cron (aus dem mv-overlay). Ist allerdings nur bei Rechnern sinnvoll, die lange an sind, weil z.B. ein cron-monthly job, einmal gestartet und dann wegen shutdown abgebrochen, erst im nächsten Moat wieder gestartet wird. Anacron ist da m.W. etwas cleverer.

----------

## Klaus Meier

Gerade noch mal getestet. Eventuell hat es ja was mit der Zeitzone zu tun. Die steht ja erst mal nicht auf local und beim ersten Start geht die Uhr 2 Stunden vor. Könnte so die Zeit sein, wo sich das System aufhängt, dass der Zeitstempel einer Datei aus der Zukunft in die Vergangenheit springt.

/etc/tempfiles.d oder /usr/lib/tempfiles.d habe ich nicht auf dem Rechner. Mit vixie-cron passiert das Gleiche wie mit cronie.

Wollte das jetzt noch mal ganz ohne cron und Änderung der Zeit testen. Keinen Dienst gestartet außer lightdm. Ergebnis: Ich habe mich bei lightdm eingeloggt, es kam der KDE Splashscreen und dann nur noch das Hintergrundbild vom lightdm.

----------

## mv

 *Klaus Meier wrote:*   

> /etc/tempfiles.d oder /usr/lib/tempfiles.d habe ich nicht auf dem Rechner.

 

War ein Typo: s/temp/tmp

Es wäre erstaunlich, wenn zumindest /usr/lib/tmpfiles.d nicht auf Deinem Rechner wäre - selbst openrc benutzt das inzwischen.

----------

## Klaus Meier

Jupp, das habe ich...

Ich habe es mal komplett gelöscht, nur um zu sehen, was passiert. Hat sich nichts geändert. Habe  es dann auch noch mal mit dem KDM versucht, gleicher Effekt.

----------

## Klaus Meier

Habe es nun noch mal probiert und aktuell läuft es seit drei Tagen mit kdm. Keine Ahnung, was da war. Es war das Update auf systemd-216, welches mich motiviert hat, es noch mal zu versuchen.

----------

## schmidicom

Ich bin mir nicht ganz sicher ob dir das was bringt aber schaden tut es sicher auch nicht.

Bei meinen Versuchen mit dem sddm und anderen DM's musste ich feststellen das sich die "Xsession"-Scripte stellenweise ziemlich unterscheiden. Und bei manchen DM's waren genau diese der Grund warum beispielsweise der Desktop in zwei Sprachen (Englisch und die eingestellte) daher kam oder solche Dinge wie der kde-misc/networkmanagement nicht funktionierten. Auch eine beliebte Fehlerquelle scheint das starten einer logind Session zu sein, je nach PAM-Konfiguration wird bei den einen DM's eine funktionierende Session aufgebaut oder eben nicht. Und ohne eine gültige Session funktioniert natürlich auch alles nicht mehr was irgendwie mit dem PolicyKit Graffel zusammen hängt.

Vielleicht kommst du deinen Problemen ja auf die Spur wenn du diese beiden Dinge ("Xsession"-Scripte und logind Sessions über PAM) mal untersuchst.

----------

## Klaus Meier

Also zur Zeit bringt mir gar nichts etwas, weil es funktioniert... Das der sddm da wohl Probleme hat, soweit war ich auch schon. Und der Rest ist mir egal, in dieser Beziehung werde ich lange nichts mehr anfassen...

Hab ständig Angst, dass es wieder kommt.

----------

