Discussion:
[systemd-devel] Should long-running child processes clear INVOCATION_ID?
Simon McVittie
2018-03-02 15:16:53 UTC
Permalink
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?

Thanks,
smcv
Lennart Poettering
2018-03-02 15:34:01 UTC
Permalink
Post by Simon McVittie
When dbus-daemon carries out a mixture of systemd and traditional
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
Loading...