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
