[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systemd user environment variables not picked up for me

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*.

> 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?

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

(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,

Attachment: signature.asc
Description: PGP signature

Reply to: