On Fri, May 06, 2022 at 09:14:20AM +0200, Giovanni Biscuolo wrote:
> Sorry I did not mention I'm not subscribed to the mailing list,
OK.
> Actually I'm not configuring it in any way, the systemd user environment
> ("systemdctl
> --user show-environment") I get is the result of the default Debian
> systemd user configuration, including XDG_DATA_DIRS: I simply dont' know
> what is configuring that
Ah. So the systemctl --user stuff is completely irrelevant? You only
thought it had some meaning, so you kept mentioning it.
> I don't have the same laptop at hand now, but on another laptop with the
> same problem (using gdm3 as display manager) the LXTerminal is a child
> of gdm-session-worker (lightdm when i checked yesterday on the other
> laptop)
That's *completely* different from what David showed:
> Inside lxterminal:
> [david@kablamm ~]$ pstree -s $$
> systemd───lightdm───lightdm───lxsession───lxpanel───x-terminal-emul───bash───pstree
I wonder why they're so different.
> It /should/ come from the sourced $GUIX_PROFILE/etc/profile but the
> content is reset (?) by "something" after the .xsession sourcing and
> before the X session process spawn (?)
The whole point of putting variables in .xsessionrc is so that they
become part of the Xsession process, and are therefore inherited by
all of its children. In a normal setup, that includes any programs
launched from .xsession (if it exists), or your x-session-manager or
x-window-manager program.
Also in a normal setup, a terminal is created as a child of the Xsession,
or as a child of the window manager.
However, you're saying that your terminal is a child of "gdm-session-worker"
(whatever that is, clearly some part of gdm3).
That process does *not* contain your .xsessionrc variables, so anything
spawned by it won't have them either.
> As I said (and forgot to mention in my first message, sorry), all other
> env variables exported by $GUIX_PROFILE/etc/profile (via .xsessionrc)
> are actually inherited, all but XDG_DATA_DIRS that is /replaced/ with a
> "hardcoded" (?) value:
I don't know what to tell you here. If your terminal is launched as a
child/grandchild of gdm, and does *not* inherit from the Xsession, then
it's not getting those variables from your .xsessionrc file.
Maybe it's getting them by some other means.
> Actually there is environment.d [3] but I still have not tried that
> approach,
I went down that rabbit hole once or twice. Maybe I can save you some
time by letting you know that it WILL NOT do anything helpful for you.
environment.d(5) DOES NOT configure the environment of an interactive
session. Please believe me, I tried everything I could think of. This
is just one of those cases where the systemd people solved a problem
that only they thought existed, and ignored the ACTUAL PROBLEM that
people wanted to solve. And, because the systemd people are so completely
out of touch with reality, they dropped their solution on us without
any real explanation of what it DOES, and they made it LOOK like it solves
the problem people would like to solve. But it doesn't.
Here's what the man page says:
Configuration files in the environment.d/ directories contain lists of
environment variable assignments for services started by the systemd
user instance.
What the bleeding hell is a "systemd user instance"? Is it a login session?
NO! No, it is not!
My best guess after all the time I wasted on this thing is that it refers
to the "systemctl --user" daemon. The same thing that neither you nor I
have ever been able to find a use for.
systemd will happily let you customize the environment of that... thing...
but not your login session.
