site  contact  subhomenews

A twisted tale of bluetoothd failing

February 10, 2020 — BarryK

I built EasyOS 2.2.9, thinking it was ready for release. Wisely though, decided to test it. On my laptop, there was no Bluetooth icon in the tray, and I found that 'bluetoothd' daemon was not running. An examination of /tmp/bootsysinit.log showed that it had tried to start, but aborted. There was also a dbus error message.

The log file showed that /etc/init.d/messagebus, which starts 'dbus-daemon', starting after /etc/init.d/bluetooth starts. However, it seems that 'bluetoothd' requires 'dbus-daemon' to already be running.

So why am I encountering this problem now? Well, it might be due to a change in /etc/rc.d/rc.sysinit. /etc/rc.d/BOOTCONSTRAINED had a variable BOOT_UDEVCHILDREN=1 (created by 3buildeasydistro in woofQ), and rc.sysinit has this line:

UDEV_LOG=2 udevd --daemon --resolve-names=early --children-max=${BOOT_UDEVDCHILDREN}

...this caused the processing of kernel uevents to be very slow, as they happened serially, one at a time. As Puppy Forum member 'rewrin' (Richard) observed several months ago, the loading of kernel modules in EasyOS was taking considerably longer that other puppies.

Now I know why, finally. I didn't realise that variable was set to 1, which goes back to when building EasyOS for ARM boards, dealing with small RAM and slow CPU -- didn't want to load it with too many parallel processes.

Now I have unset BOOT_UDEVCHILDREN, which causes udevd to run without the "--children-max=${BOOT_UDEVDCHILDREN}".

This has had a flow-on effect, one of which is 'bluetooth' running before 'messagebus'. I fixed one old bug, introduced a new one.

The solution is to run 'messagebus' earlier, so I renamed it to /etc/init.d/05-messagebus. A quick test shows that has done the trick. But, will launching 'dbus-daemon' earlier cause any other conflict? I don't think so ... touch wood. 

Tags: easy