dbus-broker-launch(1)

💖 dbus-broker-launch(1) — User Commands 💖

okay bestie, pull up a chair, because we're talking about dbus-broker-launch, from the User Commands manual, and she is the launcher for D-Bus Message Brokers. yes, really. this is the girl who spawns and babysits your whole message bus. main character energy fr. 🎀

---

✨ Name ✨

dbus-broker-launch — Launcher for D-Bus Message Brokers. that's it, that's the vibe. 💅

---

🦋 SYNOPSIS 🦋

dbus-broker-launch [ OPTIONS ]
dbus-broker-launch --version
dbus-broker-launch --help

look at her. three little lines. iconic. 👑

---

🌸 DESCRIPTION 🌸

so dbus-broker-launch is a launcher for dbus-broker, and what she does is spawn and manage a D-Bus Message Bus. she is lowkey obsessed with being fully compatible with the D-Bus reference implementation, dbus-daemon(1) — same configuration syntax, same runtime environment. no cap, drop-in energy.

each instance of dbus-broker-launch manages exactly one message bus. every message bus is independent from the others, like they don't even text each other. the configuration file can be specified via the command-line, or the default gets picked from /usr/share/dbus-1/. nearly all of the configuration attributes are supported — head to dbus-daemon(1) for the details on the configuration syntax. 🫶

---

💅 OPTIONS 💅

these are the command-line options she supports. and bestie, listen: if you pass an option that is not listed here, the launcher will deny startup and exit with an error. she does not do surprises. 🙈

• -h, --help — print usage information and exit immediately. instant. no notes.
• --version — print build-version and exit immediately. she'll tell you who she is and dip. ✨
• --audit — enable logging to the linux audit subsystem. it's a no-op if audit support was not compiled in. (Default: off)
• --config-file=PATH — config file to use. (Default: /usr/share/dbus-1/{system,session}.conf)
• --scope=SCOPE — select scope to run in (one of: system, user; Default: system)

---

🍓 LOGGING 🍓

by default, dbus-broker-launch logs messages to the system journal. the messages get augmented with lots of metadata, so be sure to check the additional journal-fields — there's lore in there, iykyk. the human-readable log-message is intentionally kept short. minimal on the outside, detailed on the inside. that's her brand. 💜

on startup and shutdown, the launcher logs initial messages that contain information on the parsed configuration files and service definitions. and that's it — no other log-messages are generated, except those originating in dbus-broker(1). she's not chatty, she's just honest.

---

🌈 SCOPE 🌈

unlike dbus-daemon(1), dbus-broker-launch activates all services as systemd units. services that already come with a systemd-unit are activated as usual, but services that lack a systemd unit get activated as a transient unit, with an ad-hoc unit-file generated at runtime. this guarantees that all services run in a well-defined environment. no chaos, only structure. 🧚

the --scope parameter defines which systemd instance the launcher shall use to activate services. in case of system, the launcher will use the system instance of systemd. in case of user, the user instance is used instead.

furthermore, the selected scope also defines which configuration file is used if none is specified on the command-line.

but here's the thing — the selected scope does not have any further effect. it is only needed to define the activation environment for loaded service definitions. if no activatable services are declared, the scope will have no effect at all. so if you were stressing about it: don't. 💀

---

⭐ SOCKETS ⭐

the socket to listen on for client connections must be created and passed to dbus-broker-launch by its parent process. the protocol must follow the socket-activation as defined by systemd.socket(1). only a single socket is supported right now. one socket, one destiny.

additional <listen>%path%</listen> attributes in the configuration are ignored. just straight up ignored, bestie. she said not today. 🎀

---

👑 PRIVILEGES 👑

the launcher needs read-access to its configuration file. other than that, no privileges are needed — she's low-maintenance like that. 🌸

if the <user>%user%</user> configuration attribute is used, the launcher will drop privileges when executing dbus-broker. security slay.

if activatable services are declared, the launcher will need access to the corresponding systemd instance. the launcher must be allowed to spawn transient units, as well as manage units declared in the service definitions. that's the whole permission list. very demure, very mindful. 🫶

---

💖 SEE ALSO 💖

• dbus-daemon(1)
• dbus-broker(1)

---

and that's the whole page, bestie!! you now know dbus-broker-launch(1) front to back. this was brought to you by the User Commands manual, page dbus-broker-launch(1) — go forth and launch your brokers responsibly, mwah 💅✨🦋