Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #224169 > unrolled thread

Systemd user environment variables not picked up for me

Back to article view | Back to linux.debian.user

Contents

  Systemd user environment variables not picked up for me Thomas Pircher <thp+debian@p5r.uk> - 2020-06-29 12:10 +0200
    Re: Systemd user environment variables not picked up for me Thomas Pircher <thp+debian@p5r.uk> - 2020-06-29 13:10 +0200
    Re: Systemd user environment variables not picked up for me Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-29 15:40 +0200
      Re: Systemd user environment variables not picked up for me Thomas Pircher <thp+debian@p5r.uk> - 2020-06-29 19:10 +0200
    Re: Systemd user environment variables not picked up for me l0f4r0@tuta.io - 2020-06-29 17:40 +0200
      Re: Systemd user environment variables not picked up for me Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-29 18:10 +0200
        Re: Systemd user environment variables not picked up for me Thomas Pircher <thp+debian@p5r.uk> - 2020-06-29 19:10 +0200
        Re: Systemd user environment variables not picked up for me Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-29 22:00 +0200
          Re: Systemd user environment variables not picked up for me Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-29 22:20 +0200
        Re: Systemd user environment variables not picked up for me l0f4r0@tuta.io - 2020-06-30 08:40 +0200
          Re: Systemd user environment variables not picked up for me Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-30 14:30 +0200

#224169 — Systemd user environment variables not picked up for me

Hi,

I'm experimenting with systemd environment variables. I have a file
~/.config/environment.d/50-default.conf where I set a few variables:

> MOZ_ENABLE_WAYLAND=1
> GDK_BACKEND=wayland
> TESTVAR=test123

However, these variables are not set in my environment when I log in. I
have tried logging in in text mode and in the GUI (sddm -> swaywm in my
case). I have tried to systemd daemon-reload and to reboot the machine,
but without much success. The environment variables are not set for me.

When I run /lib/systemd/user-environment-generators/30-systemd-environment-d-generator
from a terminal, then I see the variables being printed on stdout, so I
assume that both the file path and the syntax are correct. Something
seems to prevent the file from being loaded when I log in.

Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869144 suggests
this was working at some point for someone else. Does someone know how I
can debug this issue?

Thanks,
Thomas

[toc] | [next] | [standalone]

#224172

Thomas Pircher wrote:
> I'm experimenting with systemd environment variables.

I forgot to mention that this is on Debian testing/bullseye.

[toc] | [prev] | [next] | [standalone]

#224182

On Mon, Jun 29, 2020 at 10:42:51AM +0100, Thomas Pircher wrote:
> Hi,
> 
> I'm experimenting with systemd environment variables. I have a file
> ~/.config/environment.d/50-default.conf where I set a few variables:
> 
> > MOZ_ENABLE_WAYLAND=1
> > GDK_BACKEND=wayland
> > TESTVAR=test123
> 
> However, these variables are not set in my environment when I log in.

As far as I've been able to determine, this environment.d stuff does
*not* work with logins.  It seems to be designed to work only for
services that you launch with systemctl --user, or dbus, or something.

The documentation is horrible, so I have to use weasel-phrases like
"as far as I've been able to determine" and "seems to be".  It would
be lovely if the documentation would simply *say* what the feature is
intended to do, and how one actually uses it, including an example.

You may take comfort in the fact that you were not the first person
to waste a bunch of time trying to get this thing to do something that
it *looked* like it was supposed to do... but doesn't actually do.

[toc] | [prev] | [next] | [standalone]

#224206

Greg Wooledge wrote:
> As far as I've been able to determine, this environment.d stuff does
> *not* work with logins.

D'oh! That didn't occur to me. Re-reading the man pages with that in
mind makes more sense now. As you say, it seems to be implicitly assumed
in several places but not stated explicitly.

Thanks,
Thomas

[toc] | [prev] | [next] | [standalone]

#224193

Hi,

I'm not sure to understand what you want to achieve exactly, but aren't you supposed to use pam_env for setting/unsetting your environment variables?

Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#224198

On Mon, Jun 29, 2020 at 05:19:49PM +0200, l0f4r0@tuta.io wrote:
> I'm not sure to understand what you want to achieve exactly, but aren't you
> supposed to use pam_env for setting/unsetting your environment variables?

We can only speculate about the OP's actual goal, but I'll tell you
what *I* was hoping to achieve when I looked into this stuff a while
back.

The holy grail, for me, would have been a way to specify environment
variables that are applied to all user logins, whether by console login,
or ssh, or Display Manager, independent of the user's login shell.
And those variables must include a way to reference existing shell
variables like $HOME, so that one can (for example) set MAIL=$HOME/Maildir/
somewhere and have it actually *work*.

pam_env gives us the /etc/environment file which is potentially useful,
as it does in fact support many of the features I was looking for.  But
you cannot use reference to other shell variables there.  If you put
MAIL=$HOME/Maildir/ in /etc/environment and login, you will have the
literal characters $ H O M E in the resulting variable.

Even more subtly, it turns out that at the time this particular PAM
module runs, the HOME variable isn't even *set* yet.  So, even if you
used some module that can use existing variables, it wouldn't help
for this.  (Yes, I went down that pathway too.)

When I investigated environment.d, I was hoping that it could replace
pam_env and actually support the setting of environment variables in
user login sessions, including references to basic common variables like
HOME and LOGNAME.  The man page *looks* promising, even supporting some
of the fancier shell expansions like ${VAR:-default}.

It turns out that this environment.d thing is only used for "services",
not user logins.  Who cares about "services"?  If you need a variable to
be defined for a service to run, you'll set it in the service's unit file,
or you'll have a config file full of all the variables this service needs.
You don't need to use environment.d for that.  You don't *want* to use
environment.d for that.  Using environment.d would set the same variables
in every service.  Who does that?  What kind of setup would involve such
a thing?

So, in the end, the only way to add nontrivial, real-life variables to
all user logins is to configure *every* possible login vector and shell
individually.  There has been less than zero progress on this front in
30 years.

[toc] | [prev] | [next] | [standalone]

#224204

Greg Wooledge wrote:
> The holy grail, for me, would have been a way to specify environment
> variables that are applied to all user logins, whether by console login,
> or ssh, or Display Manager, independent of the user's login shell.

This is more or less what I try to achieve here. My use case is simpler
though, as I don't necessarily need to reference other variables, so the
PAM environment way might be what I will end up doing.

Thomas

[toc] | [prev] | [next] | [standalone]

#224211

[Multipart message — attachments visible in raw view] — view raw

On Lu, 29 iun 20, 11:52:45, Greg Wooledge wrote:
> On Mon, Jun 29, 2020 at 05:19:49PM +0200, l0f4r0@tuta.io wrote:
> > I'm not sure to understand what you want to achieve exactly, but aren't you
> > supposed to use pam_env for setting/unsetting your environment variables?
> 
> We can only speculate about the OP's actual goal, but I'll tell you
> what *I* was hoping to achieve when I looked into this stuff a while
> back.
> 
> The holy grail, for me, would have been a way to specify environment
> variables that are applied to all user logins, whether by console login,
> or ssh, or Display Manager, independent of the user's login shell.

Been there...

> And those variables must include a way to reference existing shell
> variables like $HOME, so that one can (for example) set MAIL=$HOME/Maildir/
> somewhere and have it actually *work*.

... or XDG_CONFIG_HOME, XDG_DATA_HOME.
 
> pam_env gives us the /etc/environment file which is potentially useful,
> as it does in fact support many of the features I was looking for.  But
> you cannot use reference to other shell variables there.  If you put
> MAIL=$HOME/Maildir/ in /etc/environment and login, you will have the
> literal characters $ H O M E in the resulting variable.
> 
> Even more subtly, it turns out that at the time this particular PAM
> module runs, the HOME variable isn't even *set* yet.  So, even if you
> used some module that can use existing variables, it wouldn't help
> for this.  (Yes, I went down that pathway too.)
> 
> When I investigated environment.d, I was hoping that it could replace
> pam_env and actually support the setting of environment variables in
> user login sessions, including references to basic common variables like
> HOME and LOGNAME.  The man page *looks* promising, even supporting some
> of the fancier shell expansions like ${VAR:-default}.

Yep.

> It turns out that this environment.d thing is only used for "services",
> not user logins.  Who cares about "services"?  If you need a variable to
> be defined for a service to run, you'll set it in the service's unit file,
> or you'll have a config file full of all the variables this service needs.
> You don't need to use environment.d for that.  You don't *want* to use
> environment.d for that.  Using environment.d would set the same variables
> in every service.  Who does that?  What kind of setup would involve such
> a thing?

You might find some use case for that if you try to move everything 
under XDG_CONFIG_HOME and XDG_DATA_HOME and/or don't want to override 
user .service units provided by the distro (in /usr/lib).

> So, in the end, the only way to add nontrivial, real-life variables to
> all user logins is to configure *every* possible login vector and shell
> individually.  There has been less than zero progress on this front in
> 30 years.

So far I've settled to the snippet below in *both* ~/.profile and 
~/.xsessionrc (inspired by a similar snippet in /etc/profile):


if [ -d "$HOME"/.config/environment.d ]; then
  for i in "$HOME"/.config/environment.d/*.sh; do
    if [ -r "$i" ]; then
      set -a
      . "$i"
      set +a
    fi
  done
fi


(improvements welcome)

Where the same variable needs to be set also for 'systemd --user' I just 
symlink the .sh file to a .config (or vice-versa, whatever).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#224213

On Mon, Jun 29, 2020 at 10:37:49PM +0300, Andrei POPESCU wrote:
> So far I've settled to the snippet below in *both* ~/.profile and 
> ~/.xsessionrc (inspired by a similar snippet in /etc/profile):
> 
> 
> if [ -d "$HOME"/.config/environment.d ]; then
>   for i in "$HOME"/.config/environment.d/*.sh; do
>     if [ -r "$i" ]; then
>       set -a
>       . "$i"
>       set +a
>     fi
>   done
> fi
> 
> 
> (improvements welcome)

You can drop the [ -d ] check.  If the directory doesn't exist, the glob
won't expand, and then the [ -r ] check will fail, so nothing will happen.

[toc] | [prev] | [next] | [standalone]

#224224

Hi,

29 juin 2020 à 17:52 de wooledg@eeg.ccf.org:

> The holy grail, for me, would have been a way to specify environment
> variables that are applied to all user logins, whether by console login,
> or ssh, or Display Manager, independent of the user's login shell.
> And those variables must include a way to reference existing shell
> variables like $HOME, so that one can (for example) set MAIL=$HOME/Maildir/
> somewhere and have it actually *work*.
>
> pam_env gives us the /etc/environment file which is potentially useful,
> as it does in fact support many of the features I was looking for.  But
> you cannot use reference to other shell variables there.  If you put
> MAIL=$HOME/Maildir/ in /etc/environment and login, you will have the
> literal characters $ H O M E in the resulting variable.
>
> Even more subtly, it turns out that at the time this particular PAM
> module runs, the HOME variable isn't even *set* yet.  So, even if you
> used some module that can use existing variables, it wouldn't help
> for this.  (Yes, I went down that pathway too.)
>
It seems you can reconstruct those "early" variables like the following:
HOME=/home/@{PAM_USER}

Or use @{HOME} directly since PAM 1.2.0.

Source: https://unix.stackexchange.com/questions/258246/why-does-pam-environment-not-include-home-in-my-new-path

Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#224231

On Tue, Jun 30, 2020 at 08:14:41AM +0200, l0f4r0@tuta.io wrote:
> It seems you can reconstruct those "early" variables like the following:
> HOME=/home/@{PAM_USER}
> 
> Or use @{HOME} directly since PAM 1.2.0.
> 
> Source: https://unix.stackexchange.com/questions/258246/why-does-pam-environment-not-include-home-in-my-new-path

Huh... interesting stuff.  Apparently I haven't been reading the
correct man pages, to start with.

None of this stuff is mentioned *at all* in pam_env(7).  The only thing
you can find there is "SEE ALSO  pam_env.conf(5)".

pam_env.conf(5) is far more interesting, especially this paragraph:

       The /etc/environment file specifies the environment variables to be
       set. The file must consist of simple NAME=VALUE pairs on separate
       lines. The pam_env(8) module will read the file after the pam_env.conf
       file.

So... wait, there are *two* config files, and they're *completely
different*?!  Jesus.

Taking your comments, plus the linked web page, plus the pam_env.conf(5)
man page, plus the commentary in the /etc/security/pam_env.conf file, I
performed the following experiment:

First, I added two lines to the end of /etc/security/pam_env.conf:

TEST1		DEFAULT=${HOME}/foo
TEST2		DEFAULT=@{HOME}/foo

Then I opened a new terminal window, and ran "su - greg" inside it.

unicorn:~$ su - greg
Password: 
unicorn:~$ env | grep TEST
TEST2=/home/greg/foo
TEST1=/foo

Huh.  It actually *worked*.  Astonishing.

I feel like the /etc/environment file needs some comments in it saying
"This is a useless legacy file; if you actually want to add environment
variables to user logins, see pam_env.conf(5) and put your changes in
/etc/security/pam_env.conf instead."  But then again, that would probably
be treated as live code rather than a comment, and something would
explode.

And then /etc/security/pam_env.conf needs comments that say "Use @{HOME}
instead of ${HOME}."  That can either replace or augment the current
comment that says "For example, HOME is used below several times, but
many PAM applications don't make it available by the time you need it."

Of course, none of this will actually happen, because it is Upstream
Documentation, and Debian won't want to touch it.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web