0

This error may be specific to systemd - or perhaps bluetooth :

This is a "headless" system. I would like to auto-connect my BT speaker after a reboot. Before upgrading my system from 'bookworm' to 'trixie', my (headless) system did this with no help or input from me! IOW, I didn't do anything specific during the original install/config to cause it to auto-connect the speaker at reboot; consequently I don't know where to begin to restore that. However:

I use bluetoothctl to handle my BT "configuration" tasks; for example, I can issue a command to connect my speaker: bluetoothctl connect <device-id>. I also know that systemd services bluetooth and pipewire must be "active" before a speaker connection can be made. And so in an effort to replace my former auto-connect, I wrote a short script that I could run from a user cron job:

The cron job:

@reboot /home/my/blueboot.sh >> /home/my/blueboot.log 2>&1 
#!/usr/bin/env bash # Purpose: auto-connect BT speaker LOGFILE="/home/my/blueboot.log" n=0 until systemctl is-active --quiet bluetooth && systemctl --user --quiet is-active pipewire do n=$((n + 1)) /usr/bin/sleep 1 done /usr/bin/echo "Seconds waited for bluetooth & pipewire services: $n" >> $LOGFILE /usr/bin/bluetoothctl connect B8:F6:53:AE:13:F1 >> $LOGFILE

In my blueboot.log file I get the following error message repeated many times:

Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

And of course no speaker connection.

It seems the problem is with the status check I am trying to do on pipewire. I've tried running the cron job under /etc/crontab with the user prefix:

@reboot my /home/my/blueboot.sh >> /home/my/blueboot.log 2>&1

But this does not seem to help. Nevertheless, I need to wait on bluetooth and pipewire services to be active before I can issue a successful command to bluetoothctl connect <device-id>.

How can I overcome this error, and get the status of pipewire.service from a cron job?

Improve this question
5
  • 1
    What about creating a custom systemd service instead of a cron job? Then you can configure it to lauch after the services it needs with more control than a cron. Commented Dec 2 at 15:04
  • @schrodingerscatcuriosity: That's not a bad idea, but two things put me off: 1) the fact that I'm not 100% certain what services are needed, and 2) I don't have much experience writing systemd services. Commented Dec 3 at 3:35
  • If your script worked with bluetooth and pipewire services as dependencies, we can assume that that's all needed. I'm no expert in systemd services, but asking an IA would render a usable template that you can tweak and experiment with. And that's another benefit of a service, you can edit it and reload/restart it whenever you need. I'd argue also that a cron is not the right tool since what you want is not time dependant, but order of processes dependant. Commented Dec 3 at 11:59
  • Note that in systemd there are system units (services) and user units (services). In the case of concern you would need a user service (note: NOT a system service run as a non-root user). Basically you place it under /etc/systemd/user/ (or ~/.config/systemd/user/ if you want it to be available for just one/some specific user) instead of /etc/systemd/system/. (The user manager supplies user services with the two env var mentioned in the error btw.) Commented Dec 3 at 12:12
  • Also I'm not sure if you can order a user service against bluetooth.service (which is a system one), since technically it's pulled in as of the enumeration of a bluetooth controller. With that said you probably don't need to do that anyway, since IIRC bluetoothctl would "block" until the service comes up. pipewire.service on the other hand is a user service. Commented Dec 3 at 12:13

1 Answer 1

Reset to default
0

I would have made this a comment, but there's not enough space. This "answer" reflects a couple of things I've learned - no more than that.

Part of the "solution" was given in the error message from systemctl:

Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

NOTE this portion of the error: (consider using --machine=<user>@.host --user to connect to bus of other user)

I first tried adding the USER=my env var to the top of the user crontab; that did not work. Next I tried following the advice given by systemd; that also did not work:

until (...) systemctl [email protected] --user --quiet is-active pipewire

Next I tried moving the job from the user crontab to the root crontab, and found that did work.

So - perhaps systemd is conflicted wrt how to handle permissions for access to user services; i.e. you must become root to get the status of a user service!?

EPILOGUE: My reasoning is flawed. In spite of the difficulties with systemd, waiting for these services to become active still failed to yield a successful BT device connection. I guess my question should have been something along the lines of, "What must happen before a BT device connection can be automatically made after reboot?" But Bluetooth questions are frequently quite "difficult". And so, I'll fall back to my initial solution: An @reboot cron job that sleeps for 30 seconds, and then issues a bluetoothctl connect <device id>; crude - but works.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.