On Fri, May 23, 2025 at 07:27:51PM +0200, Frédéric Danis wrote: > Hi Andrew, > > On 23/05/2025 18:31, Andrew Sayers wrote: > > > On Fri, May 23, 2025 at 01:17:22PM +0200, Frédéric Danis wrote: > > > Hi Andrew, > > > > > > On 23/05/2025 12:33, Andrew Sayers wrote: > > > > > > > On Thu, May 22, 2025 at 04:55:22PM +0200, Frédéric Danis wrote: > > > > > Hi Andrew, > > > > > > > > > > On 30/04/2025 15:14, Andrew Sayers wrote: > > > > > > > > > > > Obexd is usually run as a user service, and can exhibit surprising > > > > > > behaviour if two users are logged in at the same time. > > > > > > > > > > > > Unregister profiles when the user is detected to be off-seat. > > > > > > > > > > > > It may be impossible to detect whether a user is on-seat in some cases. > > > > > > For example, a version of obexd compiled with systemd support might be > > > > > > run outside of a systemd environment. Warn and leave services > > > > > > registered if that happens. > > > > > > > > > > > > Obexd can be run as a system service, in which case this check makes no > > > > > > sense. Disable this check when called with `--system-bus`. > > > > > > > > > > > > Obexd can also be run by a user that does not have an active session. > > > > > > For example, someone could use `ssh` to access the system. There might > > > > > > be a use case where someone needs Bluetooth access but can't log in with > > > > > > a keyboard, or there might be a security issue with doing so. This isn't > > > > > > handled explicitly by this patch, but a future patch could add support > > > > > > by calling `logind_set(FALSE)` in the same way as is currently done > > > > > > with `--system-bus`. > > > > > > > > > > > > Unregister profiles by closing private connections instead of sending > > > > > > UnregisterProfile on the shared connection. Pipewire has apparently > > > > > > found the latter to cause long shutdown delays, because bluetoothd > > > > > > may be shutting down and unable to handle this message. > > > > > > > > > > > > Based in large part on the wireplumber code mentioned by Pauli Virtanen: > > > > > > https://gitlab.freedesktop.org/pipewire/wireplumber/-/blob/master/modules/module-logind.c#L52 > > > > > > > > > > > > Other services are likely to need similar functionality, > > > > > > so I have created a gist to demonstrate the basic technique: > > > > > > https://gist.github.com/andrew-sayers/1c4a24f86a9a4c1b1e38d109f1bd1d1e > > > > > > > > > > > > Suggested-by: Pauli Virtanen <pav@xxxxxx> > > > > > > Signed-off-by: Andrew Sayers <kernel.org@xxxxxxxxxxxxxxx> > > > > > I have a problem to connect PBAP profile using obexctl, using upstream > > > > > bluetoothd and obexd built on Ubuntu 24.04, the org.bluez.obex.PhonebookAccess1 > > > > > interface doesn't appear. > > > > > > > > > > After bisecting I found that this commit cause this issue. > > > > Hmm, my guess is that seat detection isn't working properly. > > > > Could you try this gist? You should get "Active: 1" when it starts, > > > > "Active: 0" when you switch away from your current screen, and "Active: 1" > > > > when you switch back. > > > > > > > > https://gist.github.com/andrew-sayers/1c4a24f86a9a4c1b1e38d109f1bd1d1e > > > > > > > It seems to work: > > > $ ./user-on-seat > > > Active: 1 > > > Active: 0 > > > Active: 1 > > > > > > But the problem occurred while I didn't try any "seat" change. > > Yeah, I was hoping you'd get e.g. 0 / 0 / 1 as output, suggesting it was > > inactive at first but changing seats worked around the problem. > > Sorry, but this means it'll be harder to debug. Can you... > > I manually start bluetoothd and obexd, i.e. I stopped them from systemctl (disable and stop) and start them using cli: > $ src/bluetoothd -nd -E > $ obexd/src/obexd -nd > > > 1. Check whether PBAP is registered with bluetoothctl: > > > > bluetoothctl show | grep 0000112e-0000-1000-8000-00805f9b34fb > > > > You should see one line, like: > > > > UUID: Phonebook Access Client (0000112e-0000-1000-8000-00805f9b34fb) > > got: > $ client/bluetoothctl show | grep 0000112e-0000-1000-8000-00805f9b34fb > UUID: Phonebook Access Client (0000112e-0000-1000-8000-00805f9b34fb) > > > 2. Tail the bluetooth and obex logs in another terminal: > > > > sudo journalctl -f SYSLOG_IDENTIFIER=bluetoothd SYSLOG_IDENTIFIER=obexd > > > > Steps below will ask you to "make a note" in the log > > (e.g. append "about to do XYZ" to the file) - this will tell me > > which messages were triggered by which events. > > > > 3. Make a note in the log, then stop the obex service: > > > > systemctl --user stop obex.service > > > > 4. Check PBAP again: > > > > bluetoothctl show | grep 0000112e-0000-1000-8000-00805f9b34fb > > > > You should not see any output. > > Yes, no output > > > 5. Make another note in the log, then start the obex service: > > > > systemctl --user start obex.service > > > > 6. Check PBAP again: > > > > bluetoothctl show | grep 0000112e-0000-1000-8000-00805f9b34fb > > > > You should see the same as in step 1. > > Yes: > $ client/bluetoothctl show | grep 0000112e-0000-1000-8000-00805f9b34fb > UUID: Phonebook Access Client (0000112e-0000-1000-8000-00805f9b34fb) > > > 8. Make a final note in the log, then try ctrl+alt+F{7,8}. > > > > 9. Send me the full log with notes, or at least anything that jumps out at you > > > > Note: the instructions above only print things that are likely to show > > problems, and unlikely to contain anything that can't go in an e-mail. You're > > welcome to do `sudo journalctl -f` and or `bluetoothctl show` in another > > terminal and go looking for trouble :) > > I added the logs for pbap connection. > > You can find the log at https://gist.github.com/fdanis-oss/eb6fba440c6b07e9ed5a266672bdbcf3 Quick update: The above was enough to replicate the bug - thanks! I'm working on a fix, but am unlikely to have a patch before next week. Long update: Changing `g_dbus_setup_private()` to `g_dbus_setup()` in pbap.c seems to fix this problem (but introduces other problems). I think obexctl is sending a request that gets received by the normal DBus connection, which no longer routes the message through to PBAP. But I'm not yet confident enough with the codebase to be sure that's what's happening. If I'm right, the solution is probably to either revisit the idea of (un)registering things in the normal connection, or to listen for messages on PBAP's private connection. But I'm not yet confident enough with DBus to properly assess either solution. Neither of the above should take a *huge* amount of time, but will need a larger block of focussed attention than I'm likely to have this week. I might get lucky and have a patch by mid-week, but the safer assumption is that it'll be top of next week's todo list. > > -- > Frédéric Danis > Senior Software Engineer > > Collabora Ltd. > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom > Registered in England & Wales, no. 5513718 > >
