Nach Upgrade auf Mga2: Programmstarts extrem langsam

[hwm]

Hallo,

nach erfolgtem Upgrade von Mga1 auf Mga2 tritt das im Betreff erwähnte Problem auf.

Starte ich ein Programm in der Konsole, erscheint diese Meldung:

Code: Alles auswählen

_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Session management error: Could not open network socket


Das Ganze quält sich dann über 10-15 Sekunden hin, dann startet das Programm. Hier war es kwrite, merkwürdigerweise kommt diese Fehlermeldung allerdings auch bei GTK Programmen, wie gedit, dort sieht das dann so aus:

Code: Alles auswählen

_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost

(gedit:11677): EggSMClient-WARNING **: Failed to connect to the session manager: Could not open network socket


Das tritt mittlerweile bei fast jedem Programm auf.

Merkwürdig finde ich den Hinweis auf das Netzwerk, das läuft, ich kann localhost anpingen, außerdem komme ich ohne Probleme ins Internet (sonst wäre ich jetzt nicht hier).

Eine Suche im Internet ergibt einige Treffer, aber keinen, der mir irgendwie weiterhilft.

Hat jemand noch einen Tipp für mich?

[man-draker]

Könnte das ein Rechteproblem sein?
Wenn die Programme in die Verzeichnisse, in denen sie die Sockets anlegen wollen, nicht schreiben können, klemmt es halt.
Ein Beispiel dafür ist .kde (bzw. .kde4)

Code: Alles auswählen

[man-draker@master ~]$ ls .kde4
Autostart/                    socket-localhost.localdomain@
cache-localhost.localdomain@  socket-master@
cache-master@                 socket-master.jhwork@
cache-master.jhwork@          tmp-localhost.localdomain@
env/                          tmp-master@
share/                        tmp-master.jhwork@
shutdown/


[hwm]

Könnte das ein Rechteproblem sein?

Den Verdacht hatte ich auch schon, das sieht aber alles sauber aus:

Code: Alles auswählen

drwxrwxr-x 2 ego ego 4096 Apr  1 18:24 Autostart/
lrwxrwxrwx 1 ego ego   21 Jun  4 13:30 cache-linux.local -> /var/tmp/kdecache-ego/
lrwxrwxrwx 1 ego ego   21 Apr  1 18:24 cache-localhost -> /var/tmp/kdecache-ego/
drwxr-xr-x 2 ego ego 4096 Apr  5 16:11 env/
drwx------ 7 ego ego 4096 Apr  5 23:44 share/
drwxr-xr-x 2 ego ego 4096 Apr  5 16:11 shutdown/
lrwxrwxrwx 1 ego ego   16 Jun  4 13:30 socket-linux.local -> /tmp/ksocket-ego/
lrwxrwxrwx 1 ego ego   16 Apr  1 18:24 socket-localhost -> /tmp/ksocket-ego/
lrwxrwxrwx 1 ego ego   12 Jun  4 13:30 tmp-linux.local -> /tmp/kde-ego/
lrwxrwxrwx 1 ego ego   12 Apr  1 18:24 tmp-localhost -> /tmp/kde-ego/


oder mit uid/gid:

Code: Alles auswählen

drwxrwxr-x 2 500 500 4096 Apr  1 18:24 Autostart/
lrwxrwxrwx 1 500 500   21 Jun  4 13:30 cache-linux.local -> /var/tmp/kdecache-ego/
lrwxrwxrwx 1 500 500   21 Apr  1 18:24 cache-localhost -> /var/tmp/kdecache-ego/
drwxr-xr-x 2 500 500 4096 Apr  5 16:11 env/
drwx------ 7 500 500 4096 Apr  5 23:44 share/
drwxr-xr-x 2 500 500 4096 Apr  5 16:11 shutdown/
lrwxrwxrwx 1 500 500   16 Jun  4 13:30 socket-linux.local -> /tmp/ksocket-ego/
lrwxrwxrwx 1 500 500   16 Apr  1 18:24 socket-localhost -> /tmp/ksocket-ego/
lrwxrwxrwx 1 500 500   12 Jun  4 13:30 tmp-linux.local -> /tmp/kde-ego/
lrwxrwxrwx 1 500 500   12 Apr  1 18:24 tmp-localhost -> /tmp/kde-ego/


Im /var/tmp und in den beiden /tmp Verzeichnissen sieht das auch sauber aus.

[doktor5000]

Wie sieht es mit dem leeren von /tmp und /var/tmp aus?

[hwm]

Dann startet das erste Programm in normaler Geschwindigkeit, obwohl die Fehlermeldung kommt. Sobald ich dann das nächste Programm starte, tritt das Problem wieder auf: Fehlermeldung -> mindestens 15 Sekunden warten.

[lula]

Hallo,

Code: Alles auswählen

non-local host localhost

sieht mir irgendwie verdächtig aus. Benutzt Du networkmanager?
Poste mal bitte den Inhalt von /etc/hosts

Grüße,
Lutz

[hwm]

Code: Alles auswählen

# generated by drakhosts
127.0.0.1 localhost

[lula]

Hallo,

probier mal bitte als user in der shell:

Code: Alles auswählen

xhost +local:

und dann ein Programm aus der shell starten. Oder auch

Code: Alles auswählen

xhost +localhost

und wieder ein Programm starten

Grüße,
Lutz

[hwm]

Code: Alles auswählen

bash-4.2$ xhost +local:
non-network local connections being added to access control list
bash-4.2$ xhost +localhost
localhost being added to access control list

Ansonsten keine Änderung im Verhalten.

[lula]

Hallo,

hast Du mal versucht einen neuen user anzulegen und damit zu probieren?

Grüße,
Lutz

[hwm]

Bisher nicht, das würde ich aber als mittlere Katastrophe ansehen, alle Einstellungen weg etc. Ich denke mal, ich gebe auf und werde wohl eine komplette Neuinstallation mache. Auf meinem Notebook blieb mir auch nichts anderes übrig, da hat das Upgrade völlig versagt, ich saß vor einem den Bootvorgang abbrechenden Gerät. Die Upgrade Funktion scheint mir nicht so das Wahre zu sein.

[doktor5000]

Bei der kompletten Neuinstallation wären aber auch deine ganzen Einstellungen weg? Und wenn du die mitnimmst, kann es sein dass du auch den Fehler mitnimmst.
Tut es weh testhalber mal einen neuen Benutzer anzulegen und es zu versuchen?

Bzgl. abgebrochener Boot, das Errata hast du gelesen? https://wiki.mageia.org/en/Mageia_2_Errata

[lula]

Hallo,

da stimme ich dem dok zu. Bei einer Neuinstallation mußt Du das System und Deinen user neu einrichten. Ist für mich mehr Aufwand als "nur" den user.

Grüße,
Lutz

[hwm]

Ja, Errata hatte ich gelesen, da das Notebook aber sowieso nur ein Testsystem ist, war das nicht weiter tragisch und eine Neuinstallation kein Problem.

Ok, habe gerade mal einen neuen User angelegt, werde das mal versuchen.

[hwm]

So, bin umgezogen, die Probleme scheinen weg zu sein, mal beobachten. Vielen Dank an alle.

trotzdem scheint es so zu sein, das der Upgrade nicht richtig funktioniert, woran es auch immer liegen mag, Berechtigungen nicht richtig gesetzt?

[S_W]

Bei mir hat der Upgrade von einer frischen Mageia1 Installation auf die Version2 fehlerfrei funktioniert. Ich muss aber auch dazu sagen, dass mit der Mageia1 Installation nicht produktiv gearbeitet wurde also Mageia1 installiert - alle updates eingespielt und dann gleich upgrade durchgeführt!

[doktor5000]

Das Upgrade funktioniert schon richtig, allerdings bei Problemen die aus Einstellungen in deinem /home resultieren musst du schon selber ran, da kann das Upgrade nichts machen.

[man-draker]

Das Upgrade funktioniert schon richtig

Naja, nach den Rückmeldungen hier, scheint es das gerne mal auch nicht zu tun.

[doktor5000]

Wenn man mal problematische Einstellungen im /home, die nicht beeinflusst werden können, und die Sachen die im Errata dokumentiert sind rausnimmt, bleiben kaum Upgrade-Probleme übrig ... oder wie siehst du das?

[man-draker]

Wenn man mal problematische Einstellungen im /home, die nicht beeinflusst werden können, und die Sachen die im Errata dokumentiert sind rausnimmt, bleiben kaum Upgrade-Probleme übrig ... oder wie siehst du das?

Gefühlt anders.
Es müsste mal jemand durchzählen, wie viele gemeldete Probleme nach dem Update sich auf die zwei Ursachen zurück führen lassen.

Ich habe jedenfalls nur ein Update mit dem blauen Pfeil in einer weitgehend unveränderten VM versucht und das ist voll daneben gegangen. Auf den echten Rechnern habe ich einmal auf eine RC hochgezogen, die dann per Paketupdate automatisch auf "release" umgestellt wurde und einmal (im Wege der Ablösung von ML2011) die Netzinstallation durchgezogen.

[doktor5000]

Stimmt, da war ja noch das Problem mit dem Update-Applet (welches nur core_release benutzt, was auch zu Problemen führen kann). Aber auch ein Update mittels des Applets sollte man via urpmi fortsetzen können. Insgesamt sind natürlich schon recht viele Probleme aufgetreten, die teilweise durch bessere Kommunikation vorab schon hätten großteils abgefangen werden können, m.E. Verglichen mit 2010.2 -> Mageia 1 fand ich es schon als herben Rückschlag insgesamt.

[hwm]

Mist, jetzt habe ich das Problem wieder!

Nachdem ich einen neuen User angelegt hatte und den alten gelöscht hatte, funktionierte alles einwandfrei, bis auf eine Kleinigkeit: der alte User hatte die Einstellung Autologin gesetzt (ja, ich weiß, ist aber ein stationärer Rechner und wird ausschließlich von mir genutzt). Dem neuen User hatte ich auch diese Einstellung verpasst.

Irgendwo geisterte der alte User aber noch rum, denn beim Starten des KDM kam immer eine Fehlermeldung (sinngemäß: schwerer Fehler mit diesem alten User), daraufhin das Login Bild. Nach Einloggen mit dem neuen User alles einwandfrei.

Daraufhin bin ich in's MCC und habe dem neuen User das Autologin entzogen und dann wieder gegeben. Der Autologin funktioniert seitdem mit dem neuen User, die Fehlermeldung mit dem alten User kommt nicht mehr, aber jetzt habe ich wieder das im Ausgangsposting beschriebene Problem.

Weitere Probleme, die jetzt bei mir auftreten:

1. Nach Neustart wird die alte KDE Session nicht wiederhergestellt, obwohl das in den KDE Einstellungen markiert ist
2. Wie in einem anderen Posting
viewtopic.php?f=7&t=731 beschrieben, funktioniert der Runterfahren Button nicht mehr, merkwürdigerweise aber der Bildschirm sperren Button

Meiner Einschätzung nach hat das MCC hier einen schweren Bug. Ich habe mir daraufhin mal die Mühe gemacht, mir Teile des Codings vom MCC anzusehen, aber das ist hoffnungslos, weil a) in der schlimmsten Programmiersprache der Welt entwickelt und b) keinerlei Doku, keine vernünftigen Kommentare (welches Modul was macht etc.). Meine Absicht dabei war, herauszufinden: Wohin schreibt das MCC die Konfiguration. Weiß das jemand?

Langsam treibt mich das in den Wahnsinn!

[man-draker]

Meine Absicht dabei war, herauszufinden: Wohin schreibt das MCC die Konfiguration. Weiß das jemand?

Das MCC ist eine Sammlung von Modulen, die für bestimmte Aspekte der Systemeinstellungen zuständig sind. Diese Module lesen und schreiben entweder die Konfigurationsdateien jener Dienste oder rufen die dazu gehörigen Systemtools auf.

Ich schlage vor, du lässt dir alle vom MCC geöffneten Dateien ausgeben:

Code: Alles auswählen

strace -o dateien.txt -f -e open drakconf

In der Datei "dateient.txt" stehen dann alle open-Aufrufe des Programms.
(Das Paket strace bitte erforderlichenfalls nachinstallieren.)

Dabei kann es jedoch sein, dass trotz Änderung bei den Benutzereinstellungen, Zugriffe auf die Dateien /etc/passwd, /etc/shadow oder /etc/group fehlen, einfach, weil MCC die Tools useradd, userdel, usermod etc. benutzt.

Da du kdm benutzt, kann - was autologin angeht - dies hilfreich sein:

KDM Auto Login

KDM is the graphical login manager created for use with the KDE windowing system.
KDM configuration

To set KDM to automatically login your mythtv user, edit your KDM configuration file, /etc/kde3/kdm/kdmrc, to modify or include the following lines,


kdmrc

Code: Alles auswählen

[X-:0-Core]
AutoLoginDelay=0
AutoLoginEnable=true
AutoLoginUser=mythtv


[hwm]

Da du kdm benutzt, kann - was autologin angeht - dies hilfreich sein:

OK, das scheint jetzt in der Datei /etc/alternatives/kdm4-config zu stehen (Dein Hinweis bezog sich auf KDE3), dort scheint alles in Ordnung zu sein:

Code: Alles auswählen

[X-:0-Core]
AutoLoginEnable=true
AutoLoginLocked=false
AutoLoginUser=ich
ClientLogFile=

Der Autologin klappt ja auch problemlos.

In dieser Datei:
/var/lib/mageia/kde4-profiles/Default/share/config/kdmrc

fand ich noch einige Einträge mit dem alten User, das bedeutet meiner Ansicht nach, MCC setzt diese Einträge nicht richtig nach Löschen des alten Users. Ein beherztes Überschreiben des alten Users durch den neuen ergibt aber leider keine Änderung.

Kann es sein, das sich das MCC mit dem KDE4 Systemeinstellungstools beharkt? Einträge wie "Vorige Sitzung wiederherstellen" zeigen bei mir keinerlei Wirkung mehr, KDE kommt mit einem leeren Desktop hoch.

[hwm]

Das Problem scheint eindeutig mit der Autologin Funktion im MCC zusammenzuhängen. Schalte ich diese ein, tritt das Problem auf. Schalte ich sie aus, nicht mehr, jeweils nach einem Reboot.

Also lasse ich die jetzt mal ausgeschaltet.