* [PATCH] Correct the dbus service file's systemd unit name for bluez.
@ 2013-02-13 18:57 William Douglas
2013-02-23 10:48 ` Marcel Holtmann
0 siblings, 1 reply; 6+ messages in thread
From: William Douglas @ 2013-02-13 18:57 UTC (permalink / raw)
To: linux-bluetooth
Even though dbus-org.bluez.service is set as an alias for the
bluetooth.service systemd unit file, systemd will not be able to load
the bluetooth daemon without the daemon being enabled (and the
dbus-org.bluez.service file linked to bluetooth.service). This patch
allows the daemon to be loaded by other services on demand.
Signed-off-by: William Douglas <william.douglas@intel.com>
---
src/org.bluez.service | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/org.bluez.service b/src/org.bluez.service
index dd7ae8f..2a3b057 100644
--- a/src/org.bluez.service
+++ b/src/org.bluez.service
@@ -2,4 +2,4 @@
Name=org.bluez
Exec=/bin/false
User=root
-SystemdService=dbus-org.bluez.service
+SystemdService=bluetooth.service
--
1.8.1.2
--
William Douglas, Intel Open Source Technology Center
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Correct the dbus service file's systemd unit name for bluez.
2013-02-13 18:57 [PATCH] Correct the dbus service file's systemd unit name for bluez William Douglas
@ 2013-02-23 10:48 ` Marcel Holtmann
2013-02-23 18:06 ` Douglas, William
0 siblings, 1 reply; 6+ messages in thread
From: Marcel Holtmann @ 2013-02-23 10:48 UTC (permalink / raw)
To: William Douglas; +Cc: linux-bluetooth
Hi William,
> Even though dbus-org.bluez.service is set as an alias for the
> bluetooth.service systemd unit file, systemd will not be able to load
> the bluetooth daemon without the daemon being enabled (and the
> dbus-org.bluez.service file linked to bluetooth.service). This patch
> allows the daemon to be loaded by other services on demand.
as you have noticed we have this in bluetooth.service:
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
Isn't this exactly what we want anyway. The service must be enabled
first before it will ever auto-started. Otherwise it just auto-starts
and the user can never get rid of it.
Regards
Marcel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Correct the dbus service file's systemd unit name for bluez.
2013-02-23 10:48 ` Marcel Holtmann
@ 2013-02-23 18:06 ` Douglas, William
2013-02-23 21:34 ` Marcel Holtmann
0 siblings, 1 reply; 6+ messages in thread
From: Douglas, William @ 2013-02-23 18:06 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
Hi Marcel,
On Sat, Feb 23, 2013 at 2:48 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi William,
>
>> Even though dbus-org.bluez.service is set as an alias for the
>> bluetooth.service systemd unit file, systemd will not be able to load
>> the bluetooth daemon without the daemon being enabled (and the
>> dbus-org.bluez.service file linked to bluetooth.service). This patch
>> allows the daemon to be loaded by other services on demand.
>
> as you have noticed we have this in bluetooth.service:
>
> [Install]
> WantedBy=bluetooth.target
> Alias=dbus-org.bluez.service
>
> Isn't this exactly what we want anyway. The service must be enabled
> first before it will ever auto-started. Otherwise it just auto-starts
> and the user can never get rid of it.
>
Oh I didn't realize that was the intent. Is that because if it is auto
enabled there is no way for the service to be masked to avoid it from
auto starting? I was hoping to have the daemon start once it was
requested by default. Probably more of a distro choice though.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Correct the dbus service file's systemd unit name for bluez.
2013-02-23 18:06 ` Douglas, William
@ 2013-02-23 21:34 ` Marcel Holtmann
2013-02-24 20:22 ` Douglas, William
0 siblings, 1 reply; 6+ messages in thread
From: Marcel Holtmann @ 2013-02-23 21:34 UTC (permalink / raw)
To: Douglas, William; +Cc: linux-bluetooth
Hi William,
> >> Even though dbus-org.bluez.service is set as an alias for the
> >> bluetooth.service systemd unit file, systemd will not be able to load
> >> the bluetooth daemon without the daemon being enabled (and the
> >> dbus-org.bluez.service file linked to bluetooth.service). This patch
> >> allows the daemon to be loaded by other services on demand.
> >
> > as you have noticed we have this in bluetooth.service:
> >
> > [Install]
> > WantedBy=bluetooth.target
> > Alias=dbus-org.bluez.service
> >
> > Isn't this exactly what we want anyway. The service must be enabled
> > first before it will ever auto-started. Otherwise it just auto-starts
> > and the user can never get rid of it.
> >
>
> Oh I didn't realize that was the intent. Is that because if it is auto
> enabled there is no way for the service to be masked to avoid it from
> auto starting? I was hoping to have the daemon start once it was
> requested by default. Probably more of a distro choice though.
I am actually curious on what is the best way here. My current thinking
is that the daemon should be started when hardware is present. Starting
it only because of a UI applet seems silly if there is no hardware
present, but I am not sure what's the appropriate default is here.
Regards
Marcel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Correct the dbus service file's systemd unit name for bluez.
2013-02-23 21:34 ` Marcel Holtmann
@ 2013-02-24 20:22 ` Douglas, William
2013-02-25 7:54 ` Marcel Holtmann
0 siblings, 1 reply; 6+ messages in thread
From: Douglas, William @ 2013-02-24 20:22 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
On Sat, Feb 23, 2013 at 1:34 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi William,
>
>> >> Even though dbus-org.bluez.service is set as an alias for the
>> >> bluetooth.service systemd unit file, systemd will not be able to load
>> >> the bluetooth daemon without the daemon being enabled (and the
>> >> dbus-org.bluez.service file linked to bluetooth.service). This patch
>> >> allows the daemon to be loaded by other services on demand.
>> >
>> > as you have noticed we have this in bluetooth.service:
>> >
>> > [Install]
>> > WantedBy=bluetooth.target
>> > Alias=dbus-org.bluez.service
>> >
>> > Isn't this exactly what we want anyway. The service must be enabled
>> > first before it will ever auto-started. Otherwise it just auto-starts
>> > and the user can never get rid of it.
>> >
>>
>> Oh I didn't realize that was the intent. Is that because if it is auto
>> enabled there is no way for the service to be masked to avoid it from
>> auto starting? I was hoping to have the daemon start once it was
>> requested by default. Probably more of a distro choice though.
>
> I am actually curious on what is the best way here. My current thinking
> is that the daemon should be started when hardware is present. Starting
> it only because of a UI applet seems silly if there is no hardware
> present, but I am not sure what's the appropriate default is here.
That is an interesting point. I was looking at it like I do for
connman, where it will start even if there isn't any network
interfaces currently available and that is expected behavior to me.
Bluez could be waiting on a usb bluetooth adapter to be added just
like connman is waiting on a usb ethernet adapter (and it isn't
obvious to my that this is taking up a much in the way of resources or
adding a lot of wakeups but I don't know). Either way I expect an easy
to turn on and off UI component making either default simple to
correct. Right now, the connman UI I am using just presents a
bluetooth option for enable/disable but it doesn't work as is without
the service being able to autostart without being enabled manually (or
by the distro default).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Correct the dbus service file's systemd unit name for bluez.
2013-02-24 20:22 ` Douglas, William
@ 2013-02-25 7:54 ` Marcel Holtmann
0 siblings, 0 replies; 6+ messages in thread
From: Marcel Holtmann @ 2013-02-25 7:54 UTC (permalink / raw)
To: Douglas, William; +Cc: linux-bluetooth
Hi William,
> >> >> Even though dbus-org.bluez.service is set as an alias for the
> >> >> bluetooth.service systemd unit file, systemd will not be able to load
> >> >> the bluetooth daemon without the daemon being enabled (and the
> >> >> dbus-org.bluez.service file linked to bluetooth.service). This patch
> >> >> allows the daemon to be loaded by other services on demand.
> >> >
> >> > as you have noticed we have this in bluetooth.service:
> >> >
> >> > [Install]
> >> > WantedBy=bluetooth.target
> >> > Alias=dbus-org.bluez.service
> >> >
> >> > Isn't this exactly what we want anyway. The service must be enabled
> >> > first before it will ever auto-started. Otherwise it just auto-starts
> >> > and the user can never get rid of it.
> >> >
> >>
> >> Oh I didn't realize that was the intent. Is that because if it is auto
> >> enabled there is no way for the service to be masked to avoid it from
> >> auto starting? I was hoping to have the daemon start once it was
> >> requested by default. Probably more of a distro choice though.
> >
> > I am actually curious on what is the best way here. My current thinking
> > is that the daemon should be started when hardware is present. Starting
> > it only because of a UI applet seems silly if there is no hardware
> > present, but I am not sure what's the appropriate default is here.
>
> That is an interesting point. I was looking at it like I do for
> connman, where it will start even if there isn't any network
> interfaces currently available and that is expected behavior to me.
> Bluez could be waiting on a usb bluetooth adapter to be added just
> like connman is waiting on a usb ethernet adapter (and it isn't
> obvious to my that this is taking up a much in the way of resources or
> adding a lot of wakeups but I don't know). Either way I expect an easy
> to turn on and off UI component making either default simple to
> correct. Right now, the connman UI I am using just presents a
> bluetooth option for enable/disable but it doesn't work as is without
> the service being able to autostart without being enabled manually (or
> by the distro default).
in general the Bluetooth option should only be present if you have
bluetoothd running and at least one controller attached.
So my thinking is that attaching a controller will start bluetoothd and
then connmand will pick up up and present Bluetooth as technology. So
that should all work.
ConnMan actually detects at runtime the start/restart of bluetoothd.
Regards
Marcel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-02-25 7:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-13 18:57 [PATCH] Correct the dbus service file's systemd unit name for bluez William Douglas
2013-02-23 10:48 ` Marcel Holtmann
2013-02-23 18:06 ` Douglas, William
2013-02-23 21:34 ` Marcel Holtmann
2013-02-24 20:22 ` Douglas, William
2013-02-25 7:54 ` Marcel Holtmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.