[systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

[Nop]

To me, just like you, it all started with me trying to detect if
running as part of systemd service or not.
And by that I really mean: user clicked somewhere, or typed in some
command in an input box or a TE, without having to be aware that
systemd is involved under the hood or not.
I do get that it was a naive question, and so on. But still, from my
understanding, DE seems to do something wrong here (at least KDE and
Gnome).
Hence my original question: Do you think it's normal? Is it the right way?

Also, I'm a bit interested about a comment from Lennart's first anwser:
> Graphical terminal apps should really not let INVOCATION_ID leak into
> their sub-sessions, they are kinda their own thing then.

I'm on the same page as you, but I'm not sure that is for the same reasons.
So, can you please elaborate on the why graphical terminal should not
leak this and "are kinda their own thing"?
My intuition is that those TE are just "access" to a TTY, so it should
be agnostic from the fact that there is a whole desktop running as a
parent.
And, on this TTY, a textual shell is running (bash, zsh, whatever).
And that is that shell that populate the environment, reading from
.bashrc and thing like that.
So, in my naive opinion, TE should just remove all environment
variables with few exception, instead of the opposite (just filtering
few variables).
And also, I don't see why I should consider 'plasmashell' different
from that. To me, it is just another kind of shell.
Why a TE should not leak INVOCATION_ID but a <name-your-de>-shell
should while, to me, they are both the same thing: at the end of the
day they are just an interface for the user to launch apps.

Le jeu. 23 mai 2024 à 20:04, Andrei Borzenkov <arvidjaar at gmail.com> a écrit :
>
> On 23.05.2024 09:18, Nop wrote:
> >  From my terminal emulator that I start by clicking in the menu:
> > echo "kitty: $(pidof kitty) - $INVOCATION_ID" && echo "plasmashell:
> > $(pidof plasmashell) - $(sudo strings /proc/$(pidof
> > plasmashell)/environ | grep INVOCATION_ID)"
> > kitty: 4441 - e3ec804609094a139948a1887c90ac7a
> > plasmashell: 857 - INVOCATION_ID=e3ec804609094a139948a1887c90ac7a
> >
> > But indeed, looking at systemd-cgls, it is in its own scope:
> > -.slice
> > ├─user.slice
> > │ └─user-1000.slice
> > │   ├─user at 1000.service …
> > │   │ ├─session.slice
> > │   │ │ ├─plasma-plasmashell.service
> > │   │ │ │ └─857 /usr/bin/plasmashell --no-respawn
> > │   │ ├─app.slice
> > │   │ │ ├─app-kitty-96877b039d10481298f59807a062a5c5.scope
> > │   │ │ │ ├─4441 /usr/bin/kitty
> > │   │ │ │ ├─4450 /bin/zsh
> > │   │ │ │ ├─9810 systemd-cgls
> > │   │ │ ├─app-steam-68615b37d4554dc8bcdce0bb903517bb.scope
> > │   │ │ │ ├─2777 bash /home/ctxnop/.local/share/Steam/steam.sh
> > │   │ │ └─app-chromium-185faea96ff5421b8ecfb0753298c32b.scope
> > │   │ │   ├─2266 /usr/lib/chromium/chromium
> > │   │ │   ├─2269 /usr/lib/chromium/chrome_crashpad_handler --monitor-self
> >
> > Did not know about this, thank you. But it feels even more weird now:
> > for P in 857 4441 4450 2777 2269; do echo -n "$P: " && tr '\0' '\n' <
> > /proc/$P/environ | grep INV; done
> > 857: INVOCATION_ID=e3ec804609094a139948a1887c90ac7a
> > 4441: INVOCATION_ID=e3ec804609094a139948a1887c90ac7a
> > 4450: INVOCATION_ID=e3ec804609094a139948a1887c90ac7a
> > 2777: INVOCATION_ID=e3ec804609094a139948a1887c90ac7a
> > 2269: INVOCATION_ID=e3ec804609094a139948a1887c90ac7a
> >
>
> Looking here on GNOME I confirm the same behavior. Unless program
> explicitly handles INVOCATION_ID (or, I assume, any other environment
> variable set by systemd) they are inherited. I am "lucky" in that
> gnome-terminal does not propagate it, so I can use INVOCATION_ID to
> distinguish between being called from interactive shell and invoked as
> service. But I was about to add some launcher icons and they would
> certainly have the same issue as you described.
>
> But everything started by gnome-shell inherits gnome-shell
> INVOCATION_ID. Everything started by gnome-session-binary inherits
> gnome-session-binary INVOCATION_ID. Etc ...
>
> All that I am interested in is how I can distinguish between "it runs as
> part of interactive user session" or "it runs as part of systemd
> service". I do not see any way to do it.
>
> It was so simple initially until someone got brilliant idea to misuse
> systemd user instance for session management ...