Skip to content

dbus: Session bus is unreachable after brew services start dbus #279749

Description

@ouillie

brew config AND brew doctor output OR brew gist-logs <formula> link

HOMEBREW_VERSION: 5.1.8
ORIGIN: https://github.com/Homebrew/brew
HEAD: b9763ee5280dc1acb3036383b3608084eebac6b7
Last commit: 21 hours ago
Branch: stable
Core tap JSON: 27 Apr 21:20 UTC
Core cask tap JSON: 27 Apr 21:20 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DOWNLOAD_CONCURRENCY: 30
HOMEBREW_EDITOR: nvim
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 15
Homebrew Ruby: 4.0.3 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.3/bin/ruby
CPU: 15-core 64-bit dunno
Clang: 21.0.0 build 2100
Git: 2.50.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.4.1-arm64
CLT: 26.4.0.0.1774242506
Xcode: N/A
Rosetta 2: false
Your system is ready to brew.

Verification

  • My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
  • I ran brew update and am still able to reproduce my issue.
  • I have resolved all warnings from brew doctor and that did not fix my problem.
  • I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.
  • My issue is not about a failure to build a formula from source.

What were you trying to do (and why)?

The instructions for the dbus formula state:

To start the session bus now and at login:
    brew services start dbus

I'm finding that this does not work.

What happened (include all command output)?

After brew services start dbus, the session bus agent loads but no client can reach it. DBUS_SESSION_BUS_ADDRESS=launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET dbus-send --session ... fails with launchd's env var DBUS_LAUNCHD_SESSION_BUS_SOCKET does not exist, and Gtk.Application (and anything else GIO-based) fails to register a name.

The root cause is that the session plist installed by upstream dbus is half-wired on modern macOS. It declares Sockets with SecureSocketWithKey for DBUS_LAUNCHD_SESSION_BUS_SOCKET, but SecureSocketWithKey only injects that env var into the spawned daemon's process environment. It does not publish the var into the launchd user domain, which is where dbus's client-side launchd:env=... lookup goes (it shells out to launchctl getenv, per _dbus_lookup_launchd_socket in dbus/dbus-sysdeps-unix.c). Historically, <key>ServiceIPC</key><true/> and <key>OnDemand</key><false/> bridged that gap, but the formula's patch :DATA (citing upstream MR 179) strips both keys without providing a replacement. The plist also lacks RunAtLoad, so the daemon never starts unless an inbound connection arrives, which can never happen because no client can resolve the address. The system bus is unaffected because its plist is generated by the formula itself with a fixed SockPathName.

What did you expect to happen?

We should probably just mirror what system_plist already does correctly. Drop the patch :DATA block and the inreplace of bus/org.freedesktop.dbus-session.plist.in, drop the empty service do block, and add a session_plist method that writes a plist with RunAtLoad, KeepAlive on failure, and --address=unix:path=#{var}/run/dbus/session_bus_socket on the command line. Update the macOS caveat to instruct users to add export DBUS_SESSION_BUS_ADDRESS=unix:path=$(brew --prefix)/var/run/dbus/session_bus_socket to their shell profile. This uses only first-class launchd primitives, removes the dependency on deprecated ServiceIPC/OnDemand, and is structurally symmetric with the working system bus. Happy to send a PR if maintainers agree on the approach.

Step-by-step reproduction instructions (by running brew commands)

- Install the `dbus` formula on macOS (tested on Tahoe 26.4.1 arm64)
- Run `brew services start dbus`
- Test the session bus with `dbus-send --session --type=method_call --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.ListNames`

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions