On Fr, 02.03.18 15:16, Simon McVittie (s...@collabora.com) wrote:
> When dbus-daemon carries out a mixture of systemd and traditional
> (non-systemd) activation, we get a process tree like this:
>
> systemd --user (init.scope)
> |- dbus-daemon --session (dbus.service)
> | |- (babysitter process)
> | | \- gnome-shell-calendar-server [t]
> | \- (babysitter process)
> | \- dleyna-renderer-service [t]
> |- gnome-terminal-server (g-t-s.service) [s]
> \- xdg-document-portal (x-d-p.service) [s]
>
> [s]: systemd activation; [t]: traditional activation
>
> or the equivalent for the system bus.
>
> As of current git master, the dbus-daemon removes some of its environment
> variables from the environment passed to traditional D-Bus services
> like gnome-shell-calendar-server, because they are applicable to to the
> dbus-daemon but not the child. In particular JOURNAL_STREAM, LISTEN_*
> and NOTIFY_SOCKET get this treatment.
>
> However, it wasn't clear to me what this code should do with the
> INVOCATION_ID. Would it be better (less misleading) to say that
> gnome-shell-calendar-server is part of the same INVOCATION_ID as its
> dbus-daemon parent, or to say that it has no invocation ID?
So the idea was that INVOCATION_ID would be specific to each invoked
"instance" of a service, regardless of how many individual processes
it is put together.
If dbus-daemon acts as its own "super-server" for some daemons it
probably woule be smart to unset that env var for the service children
it spawns, since in that case the concept doesn't really apply that
much anymore. I figure crond is similar.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
