bluetoothd not starting at boot with udev

bluetoothd not starting at boot with udev

[Artem Makhutov]

Hello,

I am using bluez-4.45 with udev.

I have the problem that bluetoothd does not startup when the computer starts up.

I have to plug out and plug in the bluetooth dongle or restart udev after the system has started in order to get bluetooth working.

What can be done to make bluetoothd startup correctly?

Thanks, Artem

Re: bluetoothd not starting at boot with udev

[Marcel Holtmann]

Hi Artem,

> I am using bluez-4.45 with udev.
> 
> I have the problem that bluetoothd does not startup when the computer starts up.
> 
> I have to plug out and plug in the bluetooth dongle or restart udev after the system has started in order to get bluetooth working.
> 
> What can be done to make bluetoothd startup correctly?

which distro? Which version of udev? Which kernel?

Regards

Marcel

RE: bluetoothd not starting at boot with udev

[Mario_Limonciello]

Hi Marcel:

> which distro? Which version of udev? Which kernel?
Seeing this same behavior on Ubuntu 9.10 too.  Kernel 2.6.31-rc2. Udev
143.

RE: bluetoothd not starting at boot with udev

[Bastien Nocera]

On Sat, 2009-07-11 at 18:26 -0500, Mario_Limonciello@Dell.com wrote:
> Hi Marcel:
> 
> > which distro? Which version of udev? Which kernel?
> Seeing this same behavior on Ubuntu 9.10 too.  Kernel 2.6.31-rc2. Udev
> 143.

Your udev scripts are missing a call to "udevadm trigger --retry-failed"

Cheers

Re: bluetoothd not starting at boot with udev

[Mario Limonciello]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

Hi Bastien:

Bastien Nocera wrote:
> On Sat, 2009-07-11 at 18:26 -0500, Mario_Limonciello@Dell.com wrote:
>   
>
> Your udev scripts are missing a call to "udevadm trigger --retry-failed"
>
> Cheers
>   
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.
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: bluetoothd not starting at boot with udev

[Mario Limonciello]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

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.  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.
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: bluetoothd not starting at boot with udev

[Bastien Nocera]

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.

Re: bluetoothd not starting at boot with udev

[Mario Limonciello]

[-- Attachment #1.1: Type: text/plain, Size: 944 bytes --]

Hi Bastien

Bastien Nocera wrote:
> On Mon, 2009-07-13 at 18:07 -0500, Mario Limonciello wrote:
>   
>
> Which is why you need to retry the failed rules later on.
>   
OK, good to know that my suspicions were correct.
>   
>
> 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.
>   
Unfortunately, this makes no difference.  It appears that the previous
invocation of the rules is not registering as a failure.  If I remove my
extra trigger call on the bluetooth subsystem and run:

$ udevadm trigger --type=failed --verbose --dry-run
(or --retry-failed, they follow the same code path)

No devices are printed, and nothing happens.

Regards

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]