Bug#882662: gnome-session: something is resetting $PATH after .gnomerc runs, making it impossible to set a custom $PATH in .gnomerc

[Nathaniel Smith]

close 882662
thanks

On further investigation, my best guess now is that this is being
caused by some bizarre interaction between gdm3, systemd user
sessions, and the structure of my .gnomerc. Specifically, I have some
PATH setup stuff that I want to be executed exactly once per session,
so I have some code like

if [ x$PATH_IS_SETUP = x ]; then
    export PATH=blah:$PATH
    export PATH_IS_SETUP=yes
fi

What I observed in the original bug report is that PATH_IS_SETUP was
getting set, but PATH was not getting set to my custom value.

What seems to be happening is that if I log out and then back in again
in fairly quick succession, then gdm is somehow copying over part of
the previous session's environment into the new session, before it
even starts running any of the session setup code. Specifically, it's
copying over PATH_IS_SETUP, but not PATH. (Or maybe it's copying both
and then resetting PATH, or something, I don't know.) Judging from
some comments in the gdm source I suspect that this has something to
do with systemd user sessions, and the requirement to trigger it is
that my previous login's systemd session is still lingering in memory
when I log back in. But I haven't confirmed this.

In any case, this thing of copying part of the environment from
another session seems utterly bonkers to me, but at least it's not
gnome-session's fault...

On Sat, Nov 25, 2017 at 3:11 AM, Nathaniel Smith <njs at pobox.com> wrote:
> Package: gnome-session
> Version: 3.26.1-1
> Severity: important
>
> In my .gnomerc, I set a custom $PATH:
>
>   PATH=blah:$PATH
>
> I also set some other variables:
>
>   export GNOMERC_WAS_EXECUTED=yeah
>
> Until recently, this worked fine: the given $PATH was set for everything inside
> my session. Since my last upgrade, though, after logging in I find that my
> $PATH is set to the system default:
>
>   ~$ echo $PATH
>   /usr/local/bin:/usr/bin:/bin:/usr/games
>
> However, I can see that .gnomerc is still being executed, because other
> variables are set:
>
>   ~$ echo $GNOMERC_WAS_EXECUTED
>   yeah
>
> Looking at /var/log/apt/history.log, it looks like I upgraded on 2017-11-15,
> and everything was fine after that, and then I upgraded again on 2017-11-24,
> and that's when things broke. So whatever the problem is, it must be in some
> package that landed in testing between 2017-11-15 and 2017-11-24.
>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages gnome-session depends on:
> ii  gnome-session-bin      3.26.1-1
> ii  gnome-session-common   3.26.1-1
> ii  gnome-settings-daemon  3.26.2-1
> ii  gnome-shell            3.26.2-1
>
> gnome-session recommends no packages.
>
> Versions of packages gnome-session suggests:
> ii  desktop-base      9.0.5
> ii  gnome-keyring     3.20.1-1
> ii  gnome-user-guide  3.26.2-1
>
> -- no debconf information



-- 
Nathaniel J. Smith -- https://vorpus.org