how to discover starter bus w/systemd

[Lennart Poettering]

On Mi, 14.08.19 03:08, Jeremy Audet (jerebear at protonmail.com) wrote:

> I'm writing an application that's split into a sender and several receivers, and which communicate over D-Bus. The receivers make use of D-Bus' service activation [1] feature: they are started only when a message is sent to them, and they quit shortly after consuming all buffered messages.
>
> Some of the receivers are designed to consume messages from whichever message bus woke them up, regardless of whether it's a system bus, a session bus, or a custom bus. (Consuming messages from a custom bus could be especially useful for integration testing. We'll see.) Which message bus should a receiver connect to and consume messages from? The message bus at DBUS_STARTER_ADDRESS, natch.
>
> Here's the catch: this only works when a process is started directly by a message bus. If a message bus delegates to systemd, like so:
>
>     [D-BUS Service]
>     Name=name.jerebear.MyService1
>     Exec=/usr/bin/my-service
>     # Delegate to systemd.
>     SystemdService=my-service.service
>
> ...then the DBUS_STARTER_* environment variables aren't set. This is unfortunate, because systemd is far better equipped to manage processes than a message bus. (I'm especially fond of the hardening directives like NoNewPrivileges=.) This is doubly unfortunate because I'd like to support just one technique for starting the receivers, and since my app depends on systemd anyway, it's the obvious choice.
>
> Have any of y'all heard of this issue before? Is this a question that I should take somewhere else, like the systemd mailing list? How has this issue been resolved elsewhere, if at all? The closest I've found is a bug on the systemd bug tracker. [2]
>
> I've put together a reproducer. [3] You might need to log out and in again between invocations of dbus-send. If you're feeling fancy, fiddle with `files/name.jerebear.MyService1.service` as described in that file.
>
> FWIW, I'm running on up-to-date Arch Linux installs. Nothing fancy. I've not replaced dbus-daemon with dbus-broker, I'm not running a custom kernel, etc.

So, this is an omission in systemd that few people complained about so
far. Not enough people to make sure this gets fixed. ;-)

I'd be happy to merge a patch that corrects this and makes sure
systemd sets this variable too if Type=dbus is specified in a service
unit.

Until then, you could also set the env var manually, simply by doing
"Environment=DBUS_START_…", which is as good in most ways.

If you don#t want that you could also use other mechanisms to detect
the context you are invoked in: getppid() == 1 means you are forked
off PID 1, and thus are a system service. Or use
sd_pid_get_owner_uid() (as exposed by libsystemd), which will succeed
only if you are invoked in user context rather than as system
service.

Lennart

--
Lennart Poettering, Berlin