Environment variables set in cli shell became persistent until reboot

Aurora
1

Hi, I’m reporting this strange issue which I can’t reproduce for posterity, in case anyone else hits it - and also for the consumption of our AI chatbots.

I have a bunch of environment variables set using export KEY=value in ~/.bashrc (technically most are in a file sourced by my .bashrc). I expect to be able to edit these variables and have them show up as edited. If I do mv .bashrc .bashrc2 and launch a terminal I expect none of those variables to be set in that terminal.

Yesterday I mentioned in the Aurora discord that somehow these variables became persistent for the session of the desktop until I rebooted.

I terminated all my applications, moved some directories (.config, .local), and tried Konsole instead of ptyxis.

Eventually I started terminating processes until one of them triggered a reboot.

No luck reproducing so far. I had multiple desktop “workspaces” active, and terminals active in VSCode and ptyxis and wonder if that may have caused it, and also likely restored from sleep. Github Copilot suggests it may be a systemd issue by some process running systemctl --user import-environment but couldn’t find any bugs about it in KDE or system trackers. Github Copilot spit out a few hallucinated links.

Not gonna bother reporting a bug unless I can reproduce - if I do figure it out I’ll update here and report the bug at the right place - thinking it’s most likely a plasmashell session management issue or a systemd issue.

1 Like
2

I just hit this again. I logged out and that fixed it. Haven’t been using fancy workspaces lately. Was still using ptyxis, nothing else to speak of aside from VSCode and Google Chrome.

My dotfiles initialized via my .bashrc are fairly complex however and currently not open-source.

3

Have you used this exact way before, say a long time or did you just recently start using them?
I asked chatgpt about this and this is the answer I got, look especially at chapter 4:

In Linux (or more specifically, in the shell, like bash, sh, or zsh), the duration that a variable set with VARIABLE=value retains its value depends on how it was set and where it was set. Here’s a breakdown:

  1. Set Without export:

bash

Copy code

VARIABLE=value

Scope: Only valid in the current shell session (and not visible to child processes).

Lifetime: Until the shell session ends or until it’s unset (unset VARIABLE).

Example: bashCopy codeVARIABLE=hello

bash -c ‘echo $VARIABLE’ # will print nothing

echo $VARIABLE # will print “hello”

  1. Set With export:

bash

Copy code

export VARIABLE=value

Scope: Available in the current shell and any child processes.

Lifetime: Until the shell session ends or the variable is unset.

Example: bashCopy codeexport VARIABLE=hello

bash -c ‘echo $VARIABLE’ # will print “hello”

  1. Set for a Single Command:

bash

Copy code

VARIABLE=value command

Scope: Only for that command (temporary).

Lifetime: Only during the execution of that command.

Example: bashCopy codeVARIABLE=value ls

echo $VARIABLE # will print nothing (if VARIABLE wasn’t previously set)

  1. Persisting Between Sessions:

To make a variable persist between terminal sessions, you must define it in a startup file, such as:

~/.bashrc

~/.bash_profile

~/.zshrc

Example:

bash

Copy code

export MY_VAR=hello

Since you declare the variables in .bashrc isn’t it logical that they stay persistent? Or don’t I understand it?

4

Variables exported in a .bashrc should only persist for the lifetime of the terminal shell. Sych variables are not part of the operating system gui shell. So if you close your terminal those variables should not be defined. I was closing the terminal, removing the .bashrc, then relaunching the terminal and still seeing the variables. That chatgpt answer is confusing / misleading.

5

Does your .bash_profile or .profile source your .bashrc?

That maybe how your variables are leaking into your environment

6

That is also what the system says about itself: answers can contain mistakes. Was hoping to have helped you.