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
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.
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*
[email protected]
Hi Bastien:
Bastien Nocera wrote:
> On Sat, 2009-07-11 at 18:26 -0500, [email protected] 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*
[email protected]
On Sat, 2009-07-11 at 18:26 -0500, [email protected] 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
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.
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