Trying to revive 'ubtd' (Bluetooth file transfer)

PhAndersson

@lduboeuf Many thanks for the suggestion. No, I had not checked the output of busctl list. Here is what it says in the "default" state (i.e. no 'obexd' running, phone not connected to laptop over BT):

org.bluez                                   2170 bluetoothd      root             :1.40         bluetooth.service               -       -

If I then start 'obexd' manually as explained above, the output remains the same. If I then connect the phone to the laptop over BT, the output is still the same.

For what it's worth, I performed the same test on the laptop (openSUSE Leap 15.6), where 'obexd' is always running and known to be functional, and the busctl list output there also only lists 'bluetoothd', so I'm not sure whether 'obexd' is expected to appear there at all.

PhAndersson

This being said, a further test confirms that when 'obexd' is running, it does register with D-Bus, only not with the expected name:

:1.129                                      5035 obexd           phablet          :1.129        user@32011.service              -       -

(the behaviour is the same on the laptop, BTW -- there at least, none of the D-Bus services that are started by a regular user register a name on the bus, even though a 'BusName' parameter is specified in their unit file; only services started as 'root' seem allowed to do that).

lduboeuf

@PhAndersson

In Xenial, it was working, when i look at patches on Xenial, it appear there are some related to obexd, that may explain:
https://github.com/ubports/bluez-packaging/tree/xenial/debian/patches

PhAndersson

@lduboeuf That's a very good point -- thanks a lot. I'll have a look at those patches, but most of all you reminded me that I still have a working Xiaomi phone running Xenial, so I'll investigate the way the Bluez/OBEX stack is configured there.

PhAndersson

OK, first batch of results:

'obexd' is started by default on Xenial and runs with the same command-line parameters
the same two OBEX-related packages are installed, but of course their version differ (5.53 for bluez-obexd, 1.7.1 for libopenobex2)
the files provided by the 'bluez-obexd' package are the same, except for the dbus-org.bluez.obex.service unit file that is missing on Xenial
the output of busctl list | grep bluez is quite close to what it is on Focal, except that the corresponding 'systemd' unit file is not shown
the output of busctl list | grep obex shows something in lieu of a unit file ('session-c1.scope' -- what is it?), but still doesn't advertise any name for the service (see below)
further digging reveals that although 'systemd' is already present on the system, it is not used for user-related processes (i.e. no systemd --user process) -- 'obexd' has been started by upstart --user (based on its PPID)

Maybe the problem on Focal stems from a lack of integration between the OBEX daemon and systemd --user (which could also explain why the service doesn't start although enabled)?

For what it's worth, here is the output of busctl list | grep obex on Xenial:

:1.59                                             4084 obexd           phablet          :1.59         session-c1.scope          c1         -

lduboeuf

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

OK, first batch of results:

'obexd' is started by default on Xenial and runs with the same command-line parameters

the same two OBEX-related packages are installed, but of course their version differ (5.53 for bluez-obexd, 1.7.1 for libopenobex2)

the files provided by the 'bluez-obexd' package are the same, except for the dbus-org.bluez.obex.service unit file that is missing on Xenial

the output of busctl list | grep bluez is quite close to what it is on Focal, except that the corresponding 'systemd' unit file is not shown

the output of busctl list | grep obex shows something in lieu of a unit file ('session-c1.scope' -- what is it?), but still doesn't advertise any name for the service (see below)

further digging reveals that although 'systemd' is already present on the system, it is not used for user-related processes (i.e. no systemd --user process) -- 'obexd' has been started by upstart --user (based on its PPID)

Maybe the problem on Focal stems from a lack of integration between the OBEX daemon and systemd --user (which could also explain why the service doesn't start although enabled)?

For what it's worth, here is the output of busctl list | grep obex on Xenial:
:1.59                                             4084 obexd           phablet          :1.59         session-c1.scope          c1         -                  

Yes indeed, Xenial relies on upstart instead of systemd. Maybe something is missing there.
This discussion could interest core team. @peat_psuwit do you have an idea ?

PhAndersson

Further updates:

The obex.service systemd unit was in fact disabled by default. I enabled it with systemctl --user enable obex.service and then performed a full power-cycle on the phone.

After rebooting, obexd was still not running.

systemd reports the following about the service:

â obex.service - Bluetooth OBEX service
     Loaded: loaded (/usr/lib/systemd/user/obex.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/user/obex.service.d
             ââubuntu-touch-session.conf
     Active: inactive (dead)

I didn't find anything in 'journal' that could explain why systemd failed to start the unit -- obexd logs its version during startup and even that wasn't present, so I don't believe it's a case of it dying prematurely.

Of course, I'm still able to start the service manually with systemctl --user start obex.service, and in this case, it keeps running until I power-cycle the phone.

gpatel-fr

@PhAndersson

I wonder how the obex service runs at all for you. It does not for me.
On my FP5 running 24.04.1.1, I get:

phablet@ubuntu-phablet:~$ systemctl --user cat obex
# /usr/lib/systemd/user/obex.service
[Unit]
Description=Bluetooth OBEX service

[Service]
Type=dbus
BusName=org.bluez.obex
ExecStart=/usr/libexec/bluetooth/obexd

[Install]
Alias=dbus-org.bluez.obex.service

# /usr/lib/systemd/user/obex.service.d/ubuntu-touch-session.conf
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/obexd -P ftp,irmc,mas,pcsuite -r $HOME

as /usr/lib/bluetooth/obexd does not exist, the service fails to start.

EDIT: after some searching, and finding this github issue, I found the trick to add another override and after setting enable-linger for phablet with loginctl, the obex service is running after a restart.

Not that I can test anything involving Bluetooth for lack of a suitable peripheral

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

I wonder how the obex service runs at all for you. It does not for me.

@lduboeuf already mentioned that obexd wouldn't start on 24.04. I don't use 24.04 yet myself, so I can't confirm.

On my FP5 running 24.04.1.1, I get:

phablet@ubuntu-phablet:~$ systemctl --user cat obex
# /usr/lib/systemd/user/obex.service
[Unit]
Description=Bluetooth OBEX service

[Service]
Type=dbus
BusName=org.bluez.obex
ExecStart=/usr/libexec/bluetooth/obexd

[Install]
Alias=dbus-org.bluez.obex.service

# /usr/lib/systemd/user/obex.service.d/ubuntu-touch-session.conf
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/obexd -P ftp,irmc,mas,pcsuite -r $HOME

That content looks identical to what it is on 20.04.

as /usr/lib/bluetooth/obexd does not exist, the service fails to start.

Are you sure /usr/lib/bluetooth/obexd does not exist on 24.04? It is normally provided by the same package as the unit file whose content you just showed (package bluez-obexd).

EDIT: after some searching, and finding this github issue, I found the trick to add another override and after setting enable-linger for phablet with loginctl, the obex service is running after a restart.

Thanks a lot for that -- maybe this would the issue on 20.04 as well. I'll try.

Not that I can test anything involving Bluetooth for lack of a suitable peripheral

gpatel-fr

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

Are you sure /usr/lib/bluetooth/obexd does not exist on 24.04

phablet@ubuntu-phablet:~$ ls /usr/lib/bluetooth/obexd
ls: cannot access '/usr/lib/bluetooth/obexd': No such file or directory

Well, that explains it then. When this upgrade from upstart to systemd, UT was still only on focal. When upgrading to 24.04, the path was not upgraded.
On a standard Ubuntu 24.04 (not UT):
apt-file list bluez-obexd
bluez-obexd: /usr/lib/systemd/user/obex.service
bluez-obexd: /usr/libexec/bluetooth/obexd
bluez-obexd: /usr/share/dbus-1/services/org.bluez.obex.service
bluez-obexd: /usr/share/doc/bluez-obexd/changelog.Debian.gz
bluez-obexd: /usr/share/doc/bluez-obexd/copyright

yeah, that's a 24.04 thing. Before Ubuntu was putting the executable under /usr/lib.

I have filed an issue on gitlab.

PhAndersson

There is progress. I'm happy to report that the D-Bus registration issue that manifested itself through the following error message:

Error registering agent for the default adapter: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.bluez.obex was not provided by any .service files")

is resolved. My mistake. I tried to connect to OBEX over the system bus, when it runs on the session bus.

Still no file transfer, though.

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
yeah, that's a 24.04 thing. Before Ubuntu was putting the executable under /usr/lib.

I have filed an issue on gitlab.

Splendid! Many thanks.

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
EDIT: after some searching, and finding this github issue, I found the trick to add another override and after setting enable-linger for phablet with loginctl, the obex service is running after a restart.

I just tried the enable-linger trick on 20.04:

$ loginctl enable-linger

then confirmed that it was set using

$ loginctl user-status

but after power-cycling the phone, the OBEX daemon still won't start automatically even though its unit file is still enabled.

You mentioned "another override": was there something else to do?