When running /usr/libexec/bluetooth/bluetoothd the process does not background, which if it's present in the openrc runlevels (and RC_PARALLEL is not set) will cause the remainder of the processes to fail to start. Bluetooth performs as expected, but no services started after bluetooth is supposed to have finished will ever be started, and the getty prompt will not appear on any console (however, xdm may already have been started by this point, masking the problem). Due to the impact on many other services, I've marked this as major. bluetoothd -dn doesn't show any error messages, nor does bluetooth -d (which logs to syslog, but does not background). I don't know what effect adding -b to the bluez init script's start-stop-daemon would have on versions of bluetoothd that DO background, but if the effect is negligble, then this may be wise to ensure that other services continue to start. I also haven't been able to find Bluez' bug tracker to report this upstream.
Any news on this? I just tried booting my second box (which has typically much longer uptimes), and got hit with it being unable to start because openrc decided xdm should start *after* bluetoothd, so it's a bigger issue than I initially thought...
09 Jan 2014; Christian Birchinger <joker@gentoo.org> files/bluetooth-init.d-r3: The bluez 5 bluetoothd doesn't fork into background. Use start-stop-daemon --background to handle this. Thanks and sorry for the delay (I was still running Gnome 3.8 that needed bluez-4 until yesterday :S)
