Additional information: 

It _seems_ as if the described problem can, in my configuration, be provoked by starting several programs (via kicker/kmenu) while KDE is still busy starting up/restoring the previous session. 
It also _seems_ that, on the other hand, the problem can be avoided when waiting until all of KDE's disk activities have ended bevor launching any application.

I also noticed that sometimes there are KDE/DBUS communication problems without KDE complaining with the abovementioned error message.  Only the symptoms remain, e.g.:
- kpowersave tray icon is grayed out
- Amarok's xine engine cannot initialise any audio driver
- Kmix doesn't find an audio device
- Removable storage media are not recognised

I can't believe that this fugly message box has still not been removed yet. 

What? Why was this assigned to me?

I have to add that my theory in comment #1 (starting apps causes the problem) seems not to be valid after having an eye on it for several days.

The problem is, however, most annoying, as it can happen that several consecutive reboots of the OS are necessary to avoid the issue :(.

*** This bug has been marked as a duplicate of bug 202090 ***

Hm ... looks more like a dublicate of #206458. KPowersave sometimes detect not running HAL and display this as a DBUS error. This is fixed in SVN, but not checked in atm.

Could you check if HAL is running if this happen? 

HAL, PolicyKit and DBUS are all running when this happens.

I'd like to point out that the error message is not completely erraneous, as all dbus-related functionality in KDE is missing (don't know how that ist in #206458). So there is a problem with dbus, it's just not the simply problem that dbus is not running.

Also, not only kpowersave is affevted by that.

Alex, can you please try to put your system into that rather unfortunate state and check whether one of the following comands fails (please run them in the context of the X user):

- `dbus-monitor --system`
- `lshal`
- `powersave -x`

Just to make sure that D-Bus is really up and working.

OK, give me a few days as I have no access to the offending computer at the moment ;) ...

OK, now some more details. I just did a upgrade of "Factory" and am now using:

hal-0.5.8_git20060919-3
PolicyKit-0.2_git20060822-7
powersave-0.15.2-4
dbus-1-0.92-9
kpowersave-0.6.2-11

---
linux:~ # powersave -x
AdvancedPowersave
Performance     active  AC_default_scheme
Acoustic
Presentation
Powersave       battery_default_scheme
---
linux:~ # dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.23 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.23"
(has to be stopped by CTRL-C)

Created attachment 99514 [details]
Output of lshal

Thanks for the update.  This shows that D-Bus is working fine.

Alex, please tag the check box for "This comment provides the needed information. Change the status of this bug back to ASSIGNED." next time.  Otherwise the assignee probably won't reply for a long, long time ;-)

It's getting a bit confusing:

I completed my "Factory" update a few hours after posting comments #11 and #12. This additional update included, among others, packages kernel-default-2.6.18-4 and glibc-2.4.90-something.

Symptoms: HAL did start during the boot sequence, but nevertheless was reported as "unused" later. Ehm. But as the update to the new glibc/nscd messed up my system quite a bit in other aspects, too (see bug #208189), I had to revert to the 10.1-glibc-stuff (glibc-2.4-25).

In this 10.1/10.2-mixed setup the behaviour is reproducable (about 5 consecutive reboots) as follows:
Most of problems listed in comment #1 don't occur anymore, KDE does no longer complain about missing dbus - only kpowersave is still dysfunctional all the time.

get this bug, after installing firefox beta 2 & restart - I think it's just by chance, but want to let it know to you..

had to reboot several times, since that day I didn't had the bug again..

I'm daily updating to the factory packages. For about a week the problem I described in my original post doesn't occur anymore.

True, there are often problems with PolicyKit and/or HAL, but they only _seem_ to happen immediately after the factory updates, and are gone after a reboot with the updated packages.

Only kpowersave is very boneheaded and still refuses to run correctly. Features like cpu frequency seem to be unaffected, however (most of the time - sometimes not, but this might also be connected with my factory updates).

had it once again, attached several logs.... maybe they can tell you something..

christofer

Created attachment 100259 [details]
logs durig the error...

it is still a kpowersave bug..

This is maybe a sideeffect of porting KPowersave to HAL and the changes in powersave. The message is IMO missleading. We plan to provide a updated KPowersave until Alpha5+/Beta1

*** Bug 209009 has been marked as a duplicate of this bug. ***

*** Bug 208892 has been marked as a duplicate of this bug. ***

*** Bug 209598 has been marked as a duplicate of this bug. ***

*** Bug 210908 has been marked as a duplicate of this bug. ***

*** Bug 212128 has been marked as a duplicate of this bug. ***

Similar problem here. KPowersave displays this annoying message, however, KPowersave is not the source of the problem. I uninstalled it (and left only the powersave daemon running) and altough the message is gone, I still notice that dbus is totally blocked. KNetworkManager doesn't work (although the networkmanager service works) and cgwd shows an interesting message:

gkiagia@gklaptop:~> gcompizthemer -i
Usage: -i /file/to/install
27882: arguments to dbus_connection_get_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 4674.
This is normally a bug in some application using the D-Bus library.
27882: arguments to dbus_connection_set_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 4638.
This is normally a bug in some application using the D-Bus library.

** ERROR **: Not enough memory to set up DBusConnection for use with GLib
aborting...
Aborted

This still happens with Alpha5plus and is really annoying.

For me the problem has been "solved" a few days ago because smart decided that because of some dependancy problem kpowersave would have to be deleted.

smart> install kpowersave
error: Can't install kpowersave-0.6.2-12@x86_64: no package provides libpowersave_hal.so.0()(64bit)

Therefore I'm now rid of the requester, the solution, however, does not completely satisfy me ;).

FYI: The dependancies seem to be corrected, and kpowersave can be installed again. But kpowersave-0.6.2-19 still doesn't want to talk with dbus.

is it possible, that dbus just stumbles over wrong file permissions? I just saw that /etc/dbus-1/machine-id was only readable for root. I changed that and added read permissions for group and other, and got no such error anymore.

However, I am not sure that this is the cause of all trouble. 

Just for the log:

/etc/dbus-1/machine-id will move to /var/lib/dbus/machine-id.

The permissions for that fill will be 0644.

Also for the log: In case of KPowersave this isn't a problem with D-Bus. It's a problem with connect to powersave. Since we work on a new version of KPowersave for beta 2 please no more comments regarding kpowersave

*** This bug has been marked as a duplicate of bug 214881 ***

For those who want to benefit from the bugfix under SuSE 10.1 try the following:

1. Download the packages from "http://software.opensuse.org/download/DBUS/" manually.

2. Install the newer dbus-1 package in addition to the older one:
rpm --force -ivh dbus-1-0.92-8.3.i586.rpm
> rpm -q dbus-1
dbus-1-0.60-30
dbus-1-0.92-8.3

3. Update other dbus-related packages
rpm -Uvh dbus-*.rpm

4. reboot: kpowersave and automounter will work

Note: !!! Do not add this URL as an installation source since ZenWorks wants to replace the old dbus package with the newer one which will break all the dependencies with the rest of the system (see 237708) !!!

This proc helps as well:

resetdbus ()
{
    echo restarting dbus and dependent services;
    powersaved stop;
    haldaemon stop;
    dbus stop;
    dbus-cleanup-sockets /var/run/dbus/system_bus_socket;
    dbus start;
    hald start;
    powersaved start
}