Hi.
This patch adds on demand functionality for bluetooth service based on udev events.
It's adapted from Fedora [1].
Idea is that bluetoothd doesn't need to be running unless the user actually has a bluetooth device.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=484345
Cheers,
Petr
--
Petr Lautrbach, Red Hat, Inc.
On 06/08/2009 01:59 PM, Stefan Seyfried wrote:
> Petr Lautrbach wrote:
>
>> but there is running boot (changing runlevel) process, so sometime after starting dbus is started
>> bluetooth again, this time successfully
>
> Triggered by what? A init script that is always enabled? Is it checking if
> there is an adapter present? If not, it's unconditionally always starting
> bluetoothd (and thus the ondemand functionality is not strictly needed ;)
>
triggered by this code:
+has_bt_devices()
+{
+ #Look for Bluetooth adapters:
+ udevadm info --export-db | grep -q -e '/devices/.*/bluetooth/.*'
+
+ return $?
+}
+
case "$1" in
start)
echo -n "Starting $DESC:"
if $DAEMON_ENABLE && [ -x "$DAEMON_EXEC" ]; then
- $DAEMON_EXEC
- echo -n " $DAEMON_NAME"
+ if [ -z $DAEMON_ONDEMAND ] || has_bt_devices; then
+ $DAEMON_EXEC
+ echo -n " $DAEMON_NAME"
+ fi
It starts if $DAEMON_ONDEMAND is not set or if there are some bluetooth adapters.
In case that $DAEMON_ONDEMAND is set and has_bt_devices() has returned non-zero, it won't start.
Petr
--
Petr Lautrbach, Red Hat, Inc.
Petr Lautrbach wrote:
> but there is running boot (changing runlevel) process, so sometime after starting dbus is started
> bluetooth again, this time successfully
Triggered by what? A init script that is always enabled? Is it checking if
there is an adapter present? If not, it's unconditionally always starting
bluetoothd (and thus the ondemand functionality is not strictly needed ;)
Best regards,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
On 06/05/2009 04:51 PM, Stefan Seyfried wrote:
> On Thu, Jun 04, 2009 at 04:52:46PM +0200, Petr Lautrbach wrote:
>> Hi.
>>
>> This patch adds on demand functionality for bluetooth service based on udev events.
>> It's adapted from Fedora [1].
>
> JFTR: I'd appreciate if this (or something similar) was added. I have a similar hack in
> the openSUSE package (though not as elaborate as this one), and for consistency across
> distributions, having a solution upstream is preferred.
>
>> Idea is that bluetoothd doesn't need to be running unless the user actually has a bluetooth device.
>
> Just out of interest: how did you solve the "udev event for bluetooth adapter
> fires before dbus is started" probem?
>
"udev event for bluetooth adapter fires before dbus is started" can happend in these cases:
boot process or changing runlevel:
udev is started, dbus is not started yet and somebody inserts bluetooth device ->
udev calls "/etc/init.d/bluetooth start" which fails
but there is running boot (changing runlevel) process, so sometime after starting dbus is started
bluetooth again, this time successfully
running system without dbus:
bluetoothd will not run even without this feature
Regards,
Petr
--
Petr Lautrbach, Red Hat, Inc.
On Fri, Jun 05, 2009 at 06:42:00PM +0200, Stefan Seyfried wrote:
> [ -x /dev/shm/bluetooth-adapter-present ] && \
"test -e" of course
> /etc/init.d/bluetooth start
Regards,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
On Fri, Jun 05, 2009 at 05:48:26PM +0200, Marcel Holtmann wrote:
> first of all the question from Stefan needs to be handled on how we
> handle the case for udev event before D-Bus system daemon is started.
>
> Personally I think having an extra init script style for this makes no
> sense and just adds complexity in the start/stop process of the daemon.
>
> I might prefer if we add special bluetoothd --udev={start,stop} handling
> to it (including polling code for D-Bus system daemon availability).
I actually solved it like this (no, I'm not proud of it, but it works):
* instead of calling "/etc/init.d/bluetooth condstart" from udev, I call
a bluetooth.sh which basically does:
mkdir /dev/shm/bluetooth-adapter-present # this is just a marker
/bin/dbus-send --system --type=method_call --print-reply \
--reply-timeout=1000 --dest=org.bluez / org.bluez.hello
If D-Bus is already up (adapter hotplug), then the dbus-send activates
bluetoothd via dbus-activation.
* I have a second, trivial init script which is always enabled and runs
at the end of the boot process (after D-Bus start, that is) and which
just does
[ -x /dev/shm/bluetooth-adapter-present ] && \
/etc/init.d/bluetooth start
This handles the "adapter was plugged in before D-Bus was ready" case.
It's not particularly pretty, and I do not want to suggest that this is
a correct solution, but it solved the problem nicely for me.
Regards,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Johan,
> > This patch adds on demand functionality for bluetooth service based on
> > udev events. It's adapted from Fedora [1].
> >
> > Idea is that bluetoothd doesn't need to be running unless the user
> > actually has a bluetooth device.
>
> The patch looks good to me (though my udev knowledge is rather limited).
> However, I'd like to get a second opinion from Marcel before pushing
> upstream.
first of all the question from Stefan needs to be handled on how we
handle the case for udev event before D-Bus system daemon is started.
Personally I think having an extra init script style for this makes no
sense and just adds complexity in the start/stop process of the daemon.
I might prefer if we add special bluetoothd --udev={start,stop} handling
to it (including polling code for D-Bus system daemon availability).
Regards
Marcel
Hi Petr,
On Thu, Jun 04, 2009, Petr Lautrbach wrote:
> This patch adds on demand functionality for bluetooth service based on
> udev events. It's adapted from Fedora [1].
>
> Idea is that bluetoothd doesn't need to be running unless the user
> actually has a bluetooth device.
The patch looks good to me (though my udev knowledge is rather limited).
However, I'd like to get a second opinion from Marcel before pushing
upstream.
Johan
On Thu, Jun 04, 2009 at 04:52:46PM +0200, Petr Lautrbach wrote:
> Hi.
>
> This patch adds on demand functionality for bluetooth service based on udev events.
> It's adapted from Fedora [1].
JFTR: I'd appreciate if this (or something similar) was added. I have a similar hack in
the openSUSE package (though not as elaborate as this one), and for consistency across
distributions, having a solution upstream is preferred.
> Idea is that bluetoothd doesn't need to be running unless the user actually has a bluetooth device.
Just out of interest: how did you solve the "udev event for bluetooth adapter
fires before dbus is started" probem?
Best regards,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)