[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

(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:

top - 18:40:46 up  1:11,  1 user,  load average: 1.52, 1.28, 1.10
Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.6%us, 16.6%sy,  0.1%ni, 71.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4026280k total,   780796k used,  3245484k free,	21884k buffers
Swap:  8225788k total,    	0k used,  8225788k free,   273736k cached


  PID USER  	PR  NI  VIRT  RES  SHR S %CPU %MEM	TIME+  COMMAND
 1422 vdr   	10 -10  764m  41m  17m S  101  1.1  51:26.19 vdr-sxfe
 1184 vdr   	10 -10 2694m 163m  14m S	1  4.2   1:08.21 vdr
 1402 root  	20   0 	0	0	0 S	0  0.0   0:09.17 kdvb-ad-1-fe-0
 1459 root  	20   0 	0	0	0 S	0  0.0   0:26.32 cx23885[0] dvb
 4278 root  	20   0 	0	0	0 S	0  0.0   0:00.05 cx23885[0] dvb
	1 root  	20   0 24708 2680 1372 S	0  0.1   0:01.29 init
	2 root  	20   0 	0	0	0 S	0  0.0   0:00.00 kthreadd

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

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

root@yvwz:~# apt-get -s dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden NEUEN Pakete werden installiert:
  linux-headers-3.2.0-41 linux-headers-3.2.0-41-generic
  linux-image-3.2.0-41-generic
Die folgenden Pakete werden aktualisiert (Upgrade):
  libgnutls26 linux-generic linux-headers-generic linux-image-generic
  linux-libc-dev
5 aktualisiert, 3 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

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):

/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)

/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'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