Comment 4 for bug 1221618

There is absolutely no reason why delaying bluez from starting should affect S3/S4 or killswitches in any normal case, especially not in a relation with dbus, for which the connection is only established on startup.

There *is* a chance where bluetooth would start and not have dbus available, but in this case it would fail immediately on startup, which does not appear to be the issue at hand. That said, since it's a possibility I have a test patch ready.

Please attach a full copy of /var/log/syslog to this bug report so we can see all the messages from bluez and from the kernel bluetooth subsystem. It really seems to me like this is an issue caused by an incomplete initialization of the bluetooth device by the time bluez starts, which is something that really should get fixed in the kernel itself rather than as a workaround in bluez.