how to discover starter bus w/systemd
Jeremy Audet
jerebear at protonmail.com
Wed Aug 14 16:45:28 UTC 2019
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 14, 2019 4:56 AM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> On Mi, 14.08.19 03:08, Jeremy Audet (jerebear at protonmail.com) wrote:
>
> > [...]
> >
> > 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.
> >
> > [...]
>
> 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.
That would be fabulous. 🤩 And yes, Type=dbus is set in the systemd service units I've written.
If a patch is written, I'm willing to try running through the testing procedure outlined in the "hacking on systemd" guide. [1] I've never run through the procedure in full, but it looks doable.
> 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.
Several of these solutions will work. I'll think it over and make a decision. Thank you very much.
[1] https://github.com/systemd/systemd/blob/master/docs/HACKING.md
More information about the dbus
mailing list