Re: how to discover starter bus w/systemd

Lennart Poettering <[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <20190814085632.GA10516@gardel-login>
On Mi, 14.08.19 03:08, Jeremy Audet ([email protected]) 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
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.