Description of problem: Every time I use GNOME Control Center for bluetooth settings, I find it gives me the following errors in the journal logs: Oct 27 12:41:57 anass-galago dbus-daemon[1788]: [session uid=1000 pid=1788] Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service' requested by ':1.488' (uid=1000 pid=25680 comm="gnome-control-center --overview " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") Oct 27 12:41:57 anass-galago dbus-daemon[1788]: [session uid=1000 pid=1788] Activation via systemd failed for unit 'dbus-org.bluez.obex.service': Unit dbus-org.bluez.obex.service not found. When I listed files of the package: bluez-obexd, I found that real name of the service is "org.bluez.obex.service" and looks like all dbus services has ditched the convention of naming to start with "dbus-*". but the systemd service under /usr/lib/systemd/user/ has an Alias under the [install] section that should link to dbus-org.bluez.obex.service! I doubt that this is main reason F25 doesn't auto connect to my Bluetooth Headphones when I boot it up or turn on my Headphones for the first time! Version-Release number of selected component (if applicable): control-center-3.22.1-2.fc25.x86_64 bluez-5.42-2.fc25.x86_64 bluez-libs-devel-5.42-2.fc25.x86_64 bluez-cups-5.42-2.fc25.x86_64 bluez-obexd-5.42-2.fc25.x86_64 bluez-libs-5.42-2.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1. Open GNOME System Settings (A.K.A GNOME Control Center). 2. Choose Bluetooth Settings. 3. Observe `journalctl -fxn` output. Actual results: `dbus-org.bluez.obex.service` is called but not found. Expected results: `org.bluez.obex.service` is called instead. Additional info:
Those references are in bluez-obexd, not in gnome-bluetooth (where the obex sharing is implement) as it only references the services via its D-Bus name. $ grep "dbus-org.bluez.obex.service" `rpm -ql bluez-obexd` /usr/lib/systemd/user/obex.service:Alias=dbus-org.bluez.obex.service /usr/share/dbus-1/services/org.bluez.obex.service:SystemdService=dbus-org.bluez.obex.service
Hi, Does 'systemctl --user enable obex' resolve the issue? obex isn't auto-started properly. It is on my list of things to fix properly. Cheers, Don
I've tried this command, and yes, it worked! before, I was trying to enable `dbus-org.bluez.obex.service` based on a fix on Archlinux task but systemd didn't recognize it, though obex.service has an Alias in the [install] section to the old name.
*** Bug 1318441 has been marked as a duplicate of this bug. ***
This is affecting me under MATE/blueman. Unable to send files to a BT device without 'systemctl --user enable obex'.
Hi, The latest bluez package should have that resolved, starting with 5.43-3. Please try and let me know if that did not work. Cheers, Don
Hi. I have bluez-obexd-5.44-1.fc25 and I still had to run 'systemctl --user enable obex' (that creates ~/.config/systemd/user/dbus-org.bluez.obex.service → /usr/lib/systemd/user/obex.service symlink) in order to get it work.
Hi, That isn't good. I was sure I tested that to verify the %post systemd logic worked correctly. :-/ But I did that on an f24 box. Maybe f25 is slightly different. I will grab a box and play with that. Cheers, Don
Hi Miroslav, I tried again and I was able to have this work on an f25 box. I did cheat though, I ssh'd into the machine and ran python script that creates and agent that registers on the obex bus. This started the daemon fine and I was able to transfer a file from my phone to my f25 machine. I didn't run this under gnome and blueman. How are you running this? Do you have an obexd running (ps ax|grep obex)? What bluez-5.44 does is creates a global link /etc/systemd/user/dbus-org.bluez.obex.service to /usr/lib/systemd/user/obex.service. That should remove the need for a ~/.config/systemd/user link. So I am surprised it isn't working for you. Can you also verify the above global link is there? Cheers, Don
bluez 5.44 seems to fix this issue for me on my Fedora 25 system. However, there were a few cases where file sending failed with obexd[4566]: Unable to find service record I then get an error in Gnome asking me to make sure that the device is turned on. Seems like if the devices are paired but not actively connected, and you try to initiate a file send, sometimes it will fail to start the connection and it will result in an error. For the times where it correctly establishes the connection, it will send properly. Not sure if this is a known issue.
Hi Ben, Thanks for the feedback. I have not seen the situation you are seeing with the failures. The reason is probably because I don't do much failure testing. How are you getting the 'not active' state? Is it because your phone is not in range for awhile, then suddenly shows up? Or does the active connection just randomly drop without you moving the phone? The is supposed to be a passive scan going on in the background every minute or two to re-establish connections. Though you might be able to 'force' an update in the gnome panel. If you leave the phone near the computer for a few minutes, does the connection becoming 'active' again automatically? Cheers, Don
I think its intended behavior for phones? If there's no active transfer going on or bluetooth tethering it won't have an active connection with the phone. This is good because it saves battery. Once I activate bluetooth tethering or a file transfer it will initiate an active connection. I know on initial pairing though it will maintain an active connection until you restart the computer or turn off/on the computer's bluetooth device. After that, every time the computer sees the device it won't try to automatically connect unless a transfer is requested or tethering is activated. For headphones and things like that, an automatic connection is always established.
On second thought, I think the failure to send files might be related to my Android phone going into some low power mode. Not sure.
Hi Don, No, I do not have obexd running. How do I run it? I tried: service obex start service obexd start service org.bluez.obex start but none of the services seem to exist. On my system /etc/systemd/user/dbus-org.bluez.obex.service does not exist. Actually /etc/systemd/user/ directory is empty. I use this exact RPM: https://fedora.pkgs.org/25/fedora-updates-x86_64/bluez-5.44-1.fc25.x86_64.rpm.html which does not seem to contain the symlink.
Hi Miroslav, Do you have the bluez-obexd installed? Cheers, Don
Hi Don, Yes, I do.
Hi, Ok. I am going to assume the output of systemctl --global is-enabled obex and systemctl --user is-enabled obex is both 'disabled'. As root, you should be able to do systemctl --global enable obex and re-run the above command and notice the 'global' command is now enabled but the user one is still disabled. That should resolve your problem. If it does, then I have to scratch my head why the '%post' install of bluez-obexd didn't 'enable' the global one correctly. (or perhaps a 'dnf update' doesn't do it but a new install does; which would imply a 'dnf erase bluez-obexd' then a 'dnf install bluez-obexd' would do the expected thing]) Cheers, Don
systemctl --global is-enabled obex --> disabled systemctl --user is-enabled obex --> enabled After removing "~/.config/systemd/user/dbus-org.bluez.obex.service": systemctl --user is-enabled obex --> disabled Running "systemctl --global enable obex" writes: Created symlink /etc/systemd/user/dbus-org.bluez.obex.service → /usr/lib/systemd/user/obex.service and file transfer works. I tried to remove the symlink again and run "dnf reinstall bluez-obexd" but it did not create the symlink. When I look into bluez.spec (in https://fedora.pkgs.org/25/fedora-updates-x86_64/bluez-obexd-5.44-1.fc25.x86_64.rpm.html ) I do not see any "%post" directive that would look like being responsible for the creation of the symlink.
Hi, Good data points. I am wondering if selinux is causing problems with the home directory symlink or not. Good to know the global symlink works. I do not know enough about the 'dnf reinstall' command to know if it triggers the %post and %preun commands in the spec file, which is what generates the symlinks. That was why I was a 'dnf erase' and 'dnf install' should trigger the %post command. Cheers, Don
Affects Fedora 26 as well, see https://bugzilla.redhat.com/show_bug.cgi?id=1464756
(In reply to Antoine Cotten from comment #20) > Affects Fedora 26 as well, see > https://bugzilla.redhat.com/show_bug.cgi?id=1464756 That's a different bug.
Enabling global obex removed the error message for me. (for the record, I'm here because a bluetooth keyboard won't identify, bluetoothd triggers 99% cpu, and load average 4, and this error message kept looping in the logs. keyboard (HID device) shouldn't need obex, I think. Keyboard still won't identify, load average is still crazy high, but this error message is gone. continuing bugzilla search)
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Under Fedora 27, KDE, I again had to issue: sudo dnf install bluez-obexd systemctl --user start obex sudo systemctl --global enable obex to be able to send files from my mobile to a laptop, I suppose the bug should be reopened.
I've just hit the same issue with bluez-obexd-5.50-1.fc28.x86_64.
(In reply to Kamil Páral from comment #26) > I've just hit the same issue with bluez-obexd-5.50-1.fc28.x86_64. Confirmed, I can see the same on my F28 machine.
Proposing for common bugs. The use case that was broken for me, before I fixed this manually, was sending a file over bluetooth to my phone. Nothing happened, until I manually started the service.
# rpm -qa | grep bluez | sort bluez-5.50-1.fc28.x86_64 bluez-hid2hci-5.50-1.fc28.x86_64 bluez-libs-5.50-1.fc28.x86_64 bluez-obexd-5.50-1.fc28.x86_64 bluez-tools-0.2.0-0.7.git20170912.7cb788c.fc28.x86_64 # systemctl --global enable obex Created symlink /etc/systemd/user/dbus-org.bluez.obex.service → /usr/lib/systemd/user/obex.service. # systemctl start obex Failed to start obex.service: Unit obex.service not found. # systemctl start obexd Failed to start obexd.service: Unit obexd.service not found. Using XFCE. I don't think I have ever managed to get bluetooth working properly over the last decade. I only want to transfer photos/videos from my Samsung S3 and it has never worked even after managing to pair successfully once. I managed to pair it a couple of months ago, but now can not connect, and no devices are visible on either end of the connection. Looks to me like a total dog's breakfast of an application. 20 years have elapsed since bluetooth was invented, any bugs should have been ironed out years ago!
systemctl --user start obex will work. It's a user unit, not system one.
Hello, I'm on F29 kernel 4.19.10-300.fc29.x86_64, since last kernel upgrade my bluethoot keybord, freezes often. The mosuse, instead works fine. Though I installed bluez-* bluez-hid2hci-*fc29.x86_64 bluez-libs-*fc29.x86_64 bluez-obexd-*fc29.x86_64 bluez-tools-*.fc29.x86_64 and created symlink the issue still remains. Any help by me/you is appreciated Many thanks
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.