On Wed, Aug 21, 2019 at 09:19:07AM -0400, Greg Wooledge wrote:
> On Wed, Aug 21, 2019 at 02:48:45AM +0000, Vipul wrote:
> > I asked this on #gnome:gnome.org they said try ~/.config/environment.d/
Further investigation of this thing. So far, I am not impressed.
The first thing I attempted was to create a single file in this directory,
conforming to the documentation's requirements, with a single variable
in it.
wooledg:~$ ls -l .config/environment.d/69-foo.conf
-rw-r--r-- 1 wooledg voice 14 Aug 21 09:17 .config/environment.d/69-foo.conf
wooledg:~$ cat "$_"
FOO=$HOME/bar
Then, I attempted to get this variable to show up in my login environment.
My first try: su - $LOGNAME. This failed (variable not present).
My second try: logging in on tty2. This failed.
I read some more man pages, poking around, trying to figure out how
this stuff works. Or is supposed to work.
It turns out there is a command called "systemctl --user show-environment"
which is supposed to "Dump the systemd manager environment block.",
whatever THAT means. And there are some related commands, like
"set-environment". And I still have no idea what this "manager" is,
exactly, but there are "Manager Lifecycle Commands" like "daemon-reload"
to poke and prod.
So, I tried using "systemctl --user set-environment FOO=bar,baby" to
set a variable within this "manager environment block". And I was
able to see this variable when I did "systemctl --user show-environment".
But this variable DOES NOT APPEAR in my environment when I login on tty2.
Neither does the variable in my ~/.config/environment.d/*.conf file.
I tried doing "sudo systemctl daemon-reload", because the man page says
that this "will rerun all generators (see systemd.generator(7))", which
sounds like the thing that environment.d(5) was talking about.
No success. The variable still does not appear anywhere.
More poking around. I got *somewhere* after reading systemd-logind(8)
which tells me:
• Keeping track of users and sessions, their processes and their idle
state. This is implemented by allocating a systemd slice unit for
each user below user.slice, and a scope unit below it for each
concurrent session of a user. Also, a per-user service manager is
started as system service instance of user@.service for each logged
in user.
Well, that's not very clear to me, but at least I was able to find the
thing called "user.slice". And indeed, underneath that in the process
tree view, there was a thing called "user-563.slice" (563 being my UID).
As it turns out, this "user-563.slice" is *not* respawned when I logout
and back in. Logging ALL the way out of X (a pain in the ass), and then
logging out of tty1 (and tty2), and logging back in on tty1, I still
saw the start date on user-563.slice was prior to today.
So, the next thing I tried was "sudo systemctl restart user-563.slice",
while logged in as 563 on tty1. I wasn't sure if this would log me out,
so I didn't want to try it while in X.
It did not log me out, but it DID cause my variable to finally appear
in the output of show-environment:
wooledg:~$ systemctl --user show-environment | grep FOO
FOO=/home/wooledg/bar
That's... progress, then? Right?
As it turns out, the variable STILL DOES NOT APPEAR in my login session,
even after logging out and back in after restarting user-563.slice.
Next, I rebooted the whole system.
Anyone care to guess the result? No? OK, fine, I'll tell you: the
variable STILL DOES NOT APPEAR in my login session, even after a full
reboot.
wooledg:~$ env | grep FOO
wooledg:~$
You're all shocked, right?
So, I've discovered a way to make an environment variable appear in
the output of some random systemd administration command, but NOT in
an actual user's login session.
Finally, I tried to use the system-wide config directory which is
apparently successful in populating me with a QT variable, and see
if I could get it to give me one of my own.
wooledg:~$ sudo sh -c 'echo FOO=\$HOME/thissucks >
/etc/environment.d/11-foo.conf'
[sudo] password for wooledg:
wooledg:~$ su - $LOGNAME
Password:
wooledg:~$ env | grep FOO
wooledg:~$ logout
wooledg:~$ sudo systemctl restart user-563.slice
wooledg:~$ su - $LOGNAME
Password:
wooledg:~$ env | grep FOO
wooledg:~$ systemctl --user show-environment | grep FOO
Failed to connect to bus: No such file or directory
I have no idea what I broke *now*, but this shit is preposterous.
It turns out, that brokenness is only within the su - session.
systemctl --user show-environment works in all other terminals, and
in the same terminal after exiting from su -. But still no success
in getting the environment variable to show up in my actual environment,
even logging in on tty2.
wooledg:~$ ls -l /etc/environment.d
total 8
-rw-r--r-- 1 root root 20 Aug 21 10:18 11-foo.conf
-rw-r--r-- 1 root root 19 Feb 9 2019 90qt-a11y.conf
wooledg:~$ cat /etc/environment.d/90qt-a11y.conf
QT_ACCESSIBILITY=1
wooledg:~$ cat /etc/environment.d/11-foo.conf
FOO=$HOME/thissucks
Seriously, what does it TAKE? Why does QT's work but not mine?
Maybe if I wait another 10 years, someone will kill systemd and replace
it with something that doesn't suck, and then the next time a Desktop
Environment user asks for help configuring their environment, we'll be
able to say "Oh, you just edit ~/.config/qqz-profile and put commands
in there, and they'll run when you login, and it'll affect your whole
session, even the terminals, even if you run GOBLIN or the legacy GNOME
desktop."
Meanwhile, we're stuck with this.
I'll just stick with my console logins, and my login shells that actually
READ the config files that their manuals say they read, and I'll be able
to do stuff. But every time a Desktop Environment user tries to do
anything, I'll just have to point to this thread and say "Sorry, I tried,
but it looks like your Desktop Environment just can't do it."
