[gelöst] nach Neuinstallation: firefox nicht benutzbar wg. dbus problem und hohe cpu-last xineliboutput

  • moin,


    habe nach der Neu-Installation leider zwei Kümmernisse:


    1. Der Firefox aus dem VDR oder dem Menue aufgerufen ist unbenutzbar, da er praktisch nicht reagiert.
    var/log/upstart/firefox.log läuft voll mit

    Code
    (firefox:2263): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
    Failed to connect to socket /tmp/dbus-aEtCr0FEbC: Verbindungsaufbau abgelehnt
    
    
    (firefox:2263): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
    Failed to connect to socket /tmp/dbus-HBKjo4hbeC: Verbindungsaufbau abgelehnt
    
    
    (firefox:2263): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
    Failed to connect to socket /tmp/dbus-EhL0zbZ5mr: Verbindungsaufbau abgelehnt


    ein "sudo restart dbus" oder andere Restarts des vdr helfen nicht, genauso wenig wie Reboots.
    Hatte ist in diesem Thread gelesen, sollte aber ja eigentlich nicht mehr auftauchen.



    Dazu kommt
    2. der vdr-sxfe Prozess belegt einen cpu-Kern mit 100%, auch hier helfen keine Reboots:


    Ich kann leider weder über go* noch hier im Portal Hinweise finden, was ich tun könnte.
    Hättet Ihr einen Tipp für mich, wie ich Ursachenforschung betreiben kann?



    Seufz
    Franl

    Einmal editiert, zuletzt von FJe ()

  • 1) Updates einspielen (falls noch nicht geschehen)
    2) Was ist das für ein System? VDR1 oder 2 aus deiner Signatur oder was anderes?
    3) Was sagt das Syslog?
    http://www.yavdr.org/documentation/0.5/de/ch06s01.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • moin,


    danke für die Antwort.


    Es ist der nvidia vdr1 mit der SSD.
    Das syslog liegt unter pastebinit (http://paste.ubuntu.com/5637588/)
    Das übliche greppen da drin nach error usw. und dbus in /var/log/* und /var/log/upstart/* hat zumindest mir nix gezeigt.



    Updates bietet er mir an


    Sollte nicht daran liegen (kernel und gnu utils), oder?.


    bye
    frank

  • moin,


    mir ist noch was aufgefallen:


    auf dem vdrr2, da geht der firefox problemlos, läuft unter root eine dbus-session, die es beim vdr1 nicht gibt:


    ermittelt mit " locate dbus|grep \/\.dbus\/"
    vdr2 (geht):

    Code
    /home/yavdr05/.dbus/session-bus
    /home/yavdr05/.dbus/session-bus/836bf58bf273f74c17f4d300000004ef-1
    
    
    /root/.dbus/session-bus
    /root/.dbus/session-bus/836bf58bf273f74c17f4d300000004ef-1
    
    
    /var/lib/vdr/.dbus/session-bus
    /var/lib/vdr/.dbus/session-bus/836bf58bf273f74c17f4d300000004ef-1


    vdr1 (geht nicht)

    Code
    /home/frank/.dbus/session-bus
    /home/frank/.dbus/session-bus/96b5cd5e45b8ca684f4dc414000002c8-0
    /home/frank/.dbus/session-bus/96b5cd5e45b8ca684f4dc414000002c8-1
    
    
    ??? 
    
    
    /var/lib/vdr/.dbus/session-bus
    /var/lib/vdr/.dbus/session-bus/96b5cd5e45b8ca684f4dc414000002c8-1


    dafür laufen zwei sessions unter dem user.


    Was ist korrekt laut yavdr-SOLL?


    bye
    Frank

  • Moin!


    Ich hab auf meiner stable-Installation nur

    Code
    /home/lars/.dbus/session-bus
    /home/lars/.dbus/session-bus/1f6a98c2607ebae767ee8bda00000754-1


    Und Firefox läuft da problemlos (ist jetzt aber nicht gestartet, bin nur per ssh auf dem vdr).


    Keine Ahnung, warum root und vdr bei dir einen Session-Bus haben.
    Was sagt denn das syslog zu "dbus" (aber nicht "dbus2vdr")?


    Bei mir sehe ich in den Prozessen allerdings zwei dbus-daemons, der System-Bus und einer als session-bus für root.

    Code
    102        889  0.0  0.0  24072  1268 ?        Ss   20:54   0:00 dbus-daemon --system --fork --activation=upstart
    root       910  0.0  0.0  23816   436 ?        Ss   20:54   0:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session


    User 102 ist bei mir "messagebus", ist also der dbus-User.


    Lars.

  • Moin!


    In der /etc/passwd steht die 102 drin, sonst wüsste ich nicht, dass es "messagebus" ist. Keine Ahnung, warum ps das nicht anzeigt.


    Lars.

  • moin,


    ich hab's gefunden.


    Der Vergleich zwischen dem vdr 1 und vdr2 zeigte, dass die Ordner und Dateien unter
    /home/user/ beim nicht funktionierenden vdr nicht dem User sondern root gehörten.
    Also
    /home/user/.dbus gehörte root mit drwx------ statt user und dazu die Dateien im sub-dir.
    Damit konnte nur root die DAteien von user sehen und lesen.


    ein beherztes "chown -R user:user /home/user/.dbus" brachte sofort einen superflinken firefox
    über openbox ohne weitere Fehlermeldungen, auch nach reboot.
    Auch die 100% Belastung der CPU ist seitdem weg.


    Vermute folgendes:
    Hatte Problem nach der Inst mit der Bildschirmerkennung,
    hatte mich auf tty1 angemeldet und als root ein X als :0 gestartet und in dem ein vdr-frontend
    (das zeigte mir, dass es grundsätzlich geht, später dann per Bildschirmerkennung gelöst)
    Dabei ist anscheinend unter /home/user von root das .dbus angelegt worden mit den Rechten root
    (weil das der erste Start eines X war).


    Danach hat dann die X :1 session immer versucht /home/user/.dbus zu lesen,
    was wg.
    drwx------ root ... 0 .dbus
    natürlich nicht ging.


    Uff.
    So geniesst man sein Hobby, oder?


    Schönen Abend
    Frank

  • Danke, da werd ich auch nachher 'ne Tasse Bier drauf nehmen beim Surfen im Großbild.


    Bye
    Frank

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!