Bugzilla – Bug 104715
dbus not working
Last modified: 2007-06-05 09:57:43 UTC
There seems to be a problem with dbus on pre-beta-2. While dbus-daemon is running neither 'dbus-monitor --system' nor hal can connect. They fail with 'No reply within specified time'.
Please provide a strace of $ strace dbus-monitor --system
Since "No reply within specified time" mostly happens if applications are linked against a wrong version of libdbus-1 please provide $ ldd -v /usr/bin/dbus-monitor
I installed latest STABLE Autobuild snapshot via slp (with last dbus and HAL packages) and all works perfect (lshal, lshal --monitor, dbus-monitor --system, powersave, kpowersave). How installed you this pre-beta-2 ?
Danny: Thanks for testing. Steffen: If you can reproduce this bug, I have prpared D-BUS packages with verbose debug output. Please install them from mbuild g0-thoenig-3 and run D-BUS with: $ DBUS_VERBOSE=1 dbus-daemon --system --nofork
Created attachment 46135 [details] strace dbus-monitor --system
Created attachment 46136 [details] ldd -v dbus-monitor
Just checked again. It's not working. In the installation system, that is. Sure, could well be that something is missing, but I don't see what (and it worked up to beta1). You can have a look at d253.
Is this the cause for #104654 ?
strace of dbus-daemon shows: read(6, "BEGIN\r\nl\1\0\1\0\0\0\0\1\0\0\0n\0\0\0\1\1o\0\25\0\0\0"..., 2048) = 135 open("/etc/passwd", O_RDONLY) = -1 EACCES (Permission denied) though this looks sane to be: lrwxrwxrwx 1 root root 26 Aug 16 02:50 /etc/passwd -> /mounts/instsys/etc/passwd -rw-r--r-- 1 root root 697 Dec 31 1969 /mounts/instsys/etc/passwd I can not reproduce this on Danny's STABLE (as of yesterday evening, ~8pm) Anyway, d253 does not seem to be in a proper state for debugging, there are way to many zombies: inst-sys:/etc # ps axu |grep Z |wc 25 299 2102 Could we please reboot the machine?
(In reply to comment #8) > Is this the cause for #104654 ? I don't know yet. Do the systems of #104654 also have this amount of zombies? Does lshal or dbus-monitor --system for systems which are affected by #104654?
It seems this bug is the cause for #104654. While dbus is running, hwinfo --disk reports an UDI but YaST does not see the disks. After dbus crashes, hwinfo --disk does NOT report an UDI but YaST now sees the disk.
*** Bug 104654 has been marked as a duplicate of this bug. ***
As mentioned above the affected systems suffer from having a vast amount of zombies. See upcoming logs.
Created attachment 46141 [details] output of ps axu |grep defunct
Changing severity to Blocker, assigning to component Kernel.
Sorry, the zombies are normal. linuxrc doesn't currently collect orphaned children.
hald is in zombie mode. This shouldn't be normal ?!
Sure it is. It coudn't connect to dbus. See $SUBJECT.
Timo, sitting next to me debugging this, just confirmed this... strace shows: open("/etc/passwd", O_RDONLY) = -1 EACCESS (Permission denied)
see comment #9 Kernel bug ?
I just tested a CD with all beta2 but for the beta1 kernel and it doesn't work either. So it's probably not the kernel.
Another bit: dbus & hald start up ok, but hald dies with the first lshal. After that neither one work (even after restarting them).
Breaks even with 9.3 kernel. Hmm.
permissions for /etc are buggy (700) $ chmod 755 /etc fixes the problem.
They come from the bootsplash config files. That's why vga=normal helped. :-/
Ok, now hal & hwinfo work fine. But yast doesn't find disks.
reopen for yast
the wrong one