Re: Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

[Benjamin Berg <benjamin@xxxxxxxxxxxxxxxx>]

On Wed, 2024-05-22 at 17:42 +0200, Lennart Poettering wrote:
> On Mi, 22.05.24 17:13, Nop (ctxnop@xxxxxxxxx) wrote:
> 
> > Hello folks,
> > I have a question about what you guys considers to be the
> > right/expect way.
> > 
> > I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and, to
> > me, it feels like those two variables should not be propagated from
> > DE.
> 
> What precisely do you mean by "DE"? Most desktop environments these
> days use systemd as service manager for per-user services too, and
> hence they'll get a properly initialized INVOCATION_ID set for each
> service.
> 
> If you use a traditional DE that does not use systemd, then you
> shouldn't have set INVOCATION_ID since you are invoked from a PAM
> session, not from a system service, hence nothing to clean up.
> 
> Hence, I am not really grokking your question. Either you buy into
> systemd or you don't. If you do you should be in the clear and have
> valid invocation IDs, and if you don't you should also be clear and
> not have the variable set at all. So all should be good?
> 
> > I mean, if I start KDE Plasma, for example, using systemd, it will receive
> > an $INVOCATION_ID. Now I start any application by clicking around, it will
> > inherit and get the very same $INVOCATION_ID.
> 
> Applications are usually started via systemd too, so no?

Unfortunately, not (at least in GNOME), it is only done properly if the
application is launched via DBus. The GNOME Shell tries to create a
scope, but that is more of a half-assed workaround using some code in
gnome-desktop IIRC. And the patch to create scopes for all applications
launched by GLib never landed upstream because it was not entirely
correct in some corner-cases, IIRC.

Anyway, sounds like a simple bug. GNOME/KDE should just probably just
remove the INVOCATION_ID variable from their own environment so that it
cannot be inherited. Or ensure it is not inherited to a launched
application.

For GNOME, please file a bug against gnome-shell. There are a few other
places that launch applications that could also clear it. Primarily
GLib but there might be something in e.g. gnome-session.

Benjamin

> > If the application happen to be konsole or kitty (terminal
> > emulator), it still inherit the variables, so that any command run
> > inside this terminal emulator also inherit from it.  Feels really
> > weird to me, no?
> 
> Graphical terminal apps should really not let INVOCATION_ID leak into
> their sub-sessions, they are kinda their own thing then.
> 
> > I checked a bit what gnome is doing and it confused me even more:
> > all
> > applications inherit the variables but the 'gnome-terminal' filters
> > out few
> > variables (including those two) so that commands don't have it:
> > https://gitlab.gnome.org/GNOME/gnome-terminal/-/blob/master/src/terminal-client-utils.cc#L227
> 
> Seems it's doing things right then.
> 
> > What is your take on this? At which level the filter should occurs
> > if it
> > should even occurs at all?
> 
> When you open a new "sub-session" or so, and fork processes off down
> the tree, then it might make sense to unset these env vars for them.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
>