FS#45816 - [bluez] Unable to send files, dbus can't find dbus-org.bluez.obex.service

Attached to Project: Arch Linux
Opened by AnAkkk (AnAkkk) - Tuesday, 28 July 2015, 18:18 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 24 September 2015, 15:43 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

While trying to send a file through KDE's Bluedevil applet on Plasma 5, it never worked for me. I can find the following errors in journalctl on every try:
dbus-daemon[1304]: Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service'
dbus-daemon[1304]: Activation via systemd failed for unit 'dbus-org.bluez.obex.service': Unit dbus-org.bluez.obex.service failed to load: No such file or directory.
kded5[1310]: BluezQt unknown: PendingCall Error: "Unit dbus-org.bluez.obex.service failed to load: No such file or directory.

Additional info:
bluez 5.32
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Thursday, 24 September 2015, 15:43 GMT
Reason for closing:  Fixed
Comment by AnAkkk (AnAkkk) - Tuesday, 28 July 2015, 18:38 GMT
I was able to solve the issue by using:
systemctl --user start obex

Is it normal this is required? It doesn't seem to be mentioned in the wiki.
Comment by AnAkkk (AnAkkk) - Monday, 31 August 2015, 15:05 GMT
Anything new here?
I think this is a packaging problem.
obex.service should probably be in /etc/systemd/user/ instead of /usr/lib/systemd/user/, this way the bluetooth file transfers would work for all users (as soon as something request it) without the need to manually enable the service on every user.
Comment by AnAkkk (AnAkkk) - Wednesday, 02 September 2015, 23:43 GMT
Actually this might just need:
systemctl --global enable obex

in the post install script.
Comment by Jan Alexander Steffens (heftig) - Friday, 18 September 2015, 18:42 GMT
This should really be enabled by default, either by altering /usr/share/dbus-1/services/org.bluez.obex.service to point at obex.service, or by
linking /usr/lib/systemd/user/dbus-org.bluez.obex.service to obex.service.
Comment by Jan Alexander Steffens (heftig) - Friday, 18 September 2015, 18:44 GMT
To clarify, this is a bit of fallout from dbus 1.10.0-3 enabling the user bus model, which comes with SystemdService activation support. This setting used to be ignored and dbus-daemon spawned obexd itself instead of asking systemd to do it.
Comment by AnAkkk (AnAkkk) - Tuesday, 22 September 2015, 20:32 GMT
Does Andreas Radke receive notifications about bug reports assigned to him? No reply since I opened it back in july :/
Comment by Andreas Radke (AndyRTR) - Wednesday, 23 September 2015, 18:30 GMT
See  FS#37773  - is 0001-Allow-using-obexd-without-systemd-in-the-user-session.patch now fully obsolete with new DBus?

I couldn't find Fedore or Gentoo changing anything so far and also upstream seems not aware of it.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 23 September 2015, 18:36 GMT
Yes, it would be. Unless we revert the dbus change, the patch should have no noticeable effect (removing it won't fix this bug, either).

Note that other distributions (Debian especially) tend to run systemctl enable on package install.
Comment by Andreas Radke (AndyRTR) - Wednesday, 23 September 2015, 19:00 GMT
So removing that patch and using ln -s /usr/lib/systemd/user/obex.service ${pkgdir}/usr/share/dbus-1/services/org.bluez.obex.service should fix it?
Comment by Jan Alexander Steffens (heftig) - Wednesday, 23 September 2015, 19:39 GMT
ln -s obex.service ${pkgdir}/usr/lib/systemd/user/dbus-org.bluez.obex.service
Comment by Andreas Radke (AndyRTR) - Wednesday, 23 September 2015, 19:52 GMT
Please try 5.34-2 in testing.
Comment by AnAkkk (AnAkkk) - Wednesday, 23 September 2015, 20:21 GMT
Seems to fix the issue, I no longer need to enable the service.

BTW, when using kdbus, I always get an error related to the bluez dbus service, I'm not sure if it's related or not. If not, I can create a new bug report if needed:

systemd[1]: org.bluez.busname: Bus service dbus-org.bluez.service not loaded, refusing.
systemd[1]: Failed to listen on DBUS1: org.bluez.

It does succeed for org.bluez.obex though:
systemd[773]: Listening on DBUS1: org.bluez.obex.
systemd[1385]: Listening on DBUS1: org.bluez.obex.

I'm not sure what's the difference between the two.
Comment by AnAkkk (AnAkkk) - Wednesday, 23 September 2015, 20:24 GMT
$ systemctl status org.bluez.busname
● org.bluez.busname - DBUS1: org.bluez
Loaded: loaded (/usr/share/dbus-1/system-services/org.bluez.service)
Active: inactive (dead)
Docs: man:systemd-dbus1-generator(8)

sept. 23 22:23:43 pc systemd[1]: org.bluez.busname: Bus service dbus-org.bluez.service not loaded, refusing.
sept. 23 22:23:43 pc systemd[1]: Failed to listen on DBUS1: org.bluez.

Should I report this to systemd?
Comment by Jan Alexander Steffens (heftig) - Wednesday, 23 September 2015, 21:22 GMT
No; same thing, just at system level. bluetooth.service is not enabled (it uses Alias=dbus-org.bluez.service).
Comment by AnAkkk (AnAkkk) - Thursday, 24 September 2015, 10:34 GMT
You are right, enabling bluetooth.service fixes the error. I guess the same thing needs to be done in the package for the system service?
Comment by Andreas Radke (AndyRTR) - Thursday, 24 September 2015, 14:13 GMT
Packages never enable services. That's up the system admin/user.

Any further change required or is it now fixed?
Comment by AnAkkk (AnAkkk) - Thursday, 24 September 2015, 14:25 GMT
Well, technically the original issue could have been solved by a service enable as well. Isn't the same "fix" wanted for the system service as well, to prevent the error from showing up on every boot (doesn't show up right now, but will do once kdbus is enabled by default) ?

The original issue is fixed.

Loading...