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

[Nop <ctxnop@xxxxxxxxx>]

>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@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

Le jeu. 23 mai 2024 à 06:11, Andrei Borzenkov <arvidjaar@xxxxxxxxx> a écrit :
>
> On 22.05.2024 23:35, Nop wrote:
> > Sorry, just noticed that I didn't "reply to all"... So Lennart is
> > going to receive this twice...
> >
> > Le mer. 22 mai 2024 à 17:42, Lennart Poettering
> > <lennart@xxxxxxxxxxxxxx> a écrit :
> >>
> >> 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.
> >>
> >
> > Not an expert on the all of this at all. For context, I'm using KDE
> > Plasma as my daily desktop. It is launched by SDDM, which is run as a
> > systemd service.
> > I'm aware that there is some per-user services that KDE starts when
> > I'm logging in. Don't know if it use systemd for that or not, but that
> > is not important for my question.
> > I'm looking for non-service applications. Like Firefox, VLC, or
> > whatever. Those apps are started, from the DE, when user is clicking
> > an icon or something like that.
> > AFAIK, no DE uses systemd to do that. There is a component, like
> > "plasmashell", "gnomeshell", that will, by any mean, end up doing an
> > execv like syscall.
> > In my case, I straced it, plasmashell ends in Qt6Core to do a clone. I
> > didn't checked gnome.
> > Anyway, to me, those apps (firefox, vlc, ...), should not get
> > INVOCATION_ID in the first place as it is not a "service", it's not
> > "running in background". Right?
>
> Look at systemd-cgls output. In my case
>
> ...
> │   │ │ ├─app-gnome-chromium-75629.scope
> │   │ │ │ ├─75629 /usr/lib/chromium/chromium
> --show-component-extension-options --enable-gpu-r>
> │   │ │ │ ├─75648 /usr/lib/chromium/chrome_crashpad_handler
> --monitor-self --monitor-self-anno>
> │   │ │ │ ├─75650 /usr/lib/chromium/chrome_crashpad_handler
> --no-periodic-tasks --monitor-self>
> ...
>
> bor@bor-Latitude-E5450:~$ tr '\0' '\n' < /proc/75648/environ | grep INV
> INVOCATION_ID=a64b74e8b14e4a0a8bc99f3363ec3bcc
> bor@bor-Latitude-E5450:~$
>
>
> So these applications are started in their own scope. It is not just
> fork/exec, it is more involved.
>
> > I mean, it's not really a problem that it does get the variables.
> > It probably won't break anything, outside maybe ending in writing to
> > the DE's journal, which might be considered as a feature.
> >
> > But let say that the DE just generate some systemd unit to run it as a
> > service for some reason, effectively running the application as a
> > systemd service.
> > Then it should get its own INVOCATION_ID, not the one from the DE.
> > Am I correct?
> >
>
> Define "INVOCATION_ID from DE". Show how you determine it, show the
> actual values of "INVOCATION_ID of DE" and "INVOCATION_ID of your process".
>
> >>
> >> 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?
> >
> >
> > For the context, my question did pop up exactly because it does.
> > I was working on an application that wants to detect if it run as a
> > systemd service or not, because if it is it should log using
> > sd-journal, if not it should log printing on stderr.
> > So I quickly found on the JOURNAL_STREAM variable that seems to be
> > exactly what I needed. I naively tried to just test if that variable
> > is set to decide if I log onto stderr or sd-journal.
> > I know that this is naive and probably won't work. But it pointed me
> > to the fact that any application started from KDE Plasma session is
> > actually started by "/usr/bin/plasmashell", which is indeed a systemd
> > service.
> > Thus, it receive its own INVOCATION_ID, which is inherited by all
> > applications started from the graphical environment. So that my
> > Firefox, my VLC, all gets the very same INVOCATION_ID and
> > JOURNAL_STREAM as the plasmashell.
> > This indeed includes konsole and kitty (which are my main terminal
> > emulator), so that any commands I type in it also receive the
> > INVOCATION_ID and JOURNAL_STREAM.
> > This feels wrong to me at first place. That is why I'm asking if this
> > is the intended behavior.
> >
>
> Show output of systemd-cgls and indicate which processes have the
> (wrong) INVOCATION_ID.
>
> >>
> >>
> >>> 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.
> >
> >
> > At first I agree with this. That is obviously not the case with
> > konsole and kitty. Didn't tried more terminals but I'm quite sure that
> > most of them just don't cleanup that.
> > Which makes me wondering if it should be the job of the terminal
> > emulator in the first place?
> > To me an application like kitty isn't bounded to systemd at all, not
> > even with a DE.
> > This is why I was asking if it should rather be the job of the DE it self.
> > By that I mean that, for example, when Plasma is starting an
> > application using a systemd unit, then it will get its INVOCATION_ID,
> > just as expected, already the case, nothing to be done here.
> > But if it runs an application using fork/clone/execv/whatever then it
> > should not leak its INVOCATION_ID.
> > Considering that there is way less DE than random applications, and DE
> > knows if there are bounded or not to systemd while random apps don't,
> > to me it makes more sense.
> > For instance, I did make a test: added 2 qunsetenv here
> > https://github.com/KDE/plasma-workspace/blob/master/shell/main.cpp#L61
> > to get rid of INVOCATION_ID and JOURNAL_STREAM (did search before if
> > it uses any of those, it did not).
> > Everything seems to work nicely (was just a quick test, might have
> > consequences I'm not aware of).
> >
> >>
> >>
> >>> 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
>