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

[Nop]

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 at poettering.net> a écrit :
>
> On Mi, 22.05.24 17:13, Nop (ctxnop at gmail.com) 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?
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?

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

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