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

Thu May 23 04:11:01 UTC 2024

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

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 at bor-Latitude-E5450:~$ tr '\0' '\n' < /proc/75648/environ | grep INV
INVOCATION_ID=a64b74e8b14e4a0a8bc99f3363ec3bcc
bor at 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