Re: bluetoothd not starting at boot with udev

[Bastien Nocera <hadess@hadess.net>]

On Mon, 2009-07-13 at 18:07 -0500, Mario Limonciello wrote:
> Hi Bastien:
> 
> Mario Limonciello wrote:
> > Hi Bastien:
> >
> > Bastien Nocera wrote:
> >   
> > Currently in the Ubuntu udev init script there is a call to 'udevadm
> > trigger' (without any arguments).  Without any arguments it appears the
> > default is "--type=devices".  When I add --type=failed (--retry-failed
> > is deprecated), the system fails to boot up to X.  If I return it back
> > to it's old state and add a second call right afterward of
> > "--type=failed", there is no difference in behavior.  bluetoothd still
> > fails to spawn by the udev rule.
> >   
> I'm actually suspecting that this is caused by dbus daemon not being
> spawned early enough for bluetoothd to have access to.

Which is why you need to retry the failed rules later on.

>   I've come to
> this conclusion by putting a shell wrapper around bluetoothd and
> capturing exit code status to see that it does get spawned at startup
> but immediately exits.  I put a pgrep at the same time to check for
> dbus, and didn't see it running.
> 
> How are you ensuring that dbus is running by the time that udev starts
> processing rules in Fedora then?
> 
> For now the only solution I can come up with is to maintain an init
> script that runs "udevadm trigger --subsystem-match=bluetooth".  Since
> multiple invocations of bluetoothd --udev won't harm the system, it's
> not that horrible of a workaround, but still ideally would like to lose
> the init script altogether.

You need to call with the --retry-failed, after the basics of the system
have been brought up. This means starting up D-Bus, mounting network
filesystems, etc.