Specifiers in user units don't use environment.d values

[hseg]

systemd version the issue has been seen with

254.5-1-arch

Used distribution

Arch Linux

Linux kernel version used

6.5.5-arch1-1

CPU architectures issue was seen on

x86_64

Component

systemctl

Expected behaviour you didn't see

Units started with user manager would have specifiers referring to XDG variables (%C, %E, %L, %S) expand to reflect XDG settings.

Unexpected behaviour you saw

Instead, systemd seems to have passed the XDG defaults to the unit (see attached log)

Steps to reproduce the problem

Fresh user, with

#~/.config/environment.d/00-xdg.conf
LOCALDIR=/home/test/.local
XDG_CONFIG_HOME=${LOCALDIR}/etc
XDG_CACHE_HOME=${LOCALDIR}/var/cache
XDG_STATE_HOME=${LOCALDIR}/var/state

and

#~/.config/systemd/user/check-xdg.service
[Service]
Type=oneshot
ExecStart=echo "XDG_CACHE_HOME=" %C
ExecStart=echo "XDG_CONFIG_HOME=" %E
ExecStart=echo "XDG_STATE_HOME/log=" %L
ExecStart=echo "XDG_STATE_HOME=" %S

[Install]
WantedBy=default.target

(note: for some reason, placing the unit under $XDG_CONFIG_HOME/systemd/user/ rendered it visible to systemd-analyze --user verify but not systemctl --user start, but ran out of time diagnosing this)

and

#~/check-xdg.sh
echo "XDG_CACHE_HOME=$XDG_CACHE_HOME"
echo "XDG_CONFIG_HOME=$XDG_CONFIG_HOME"
echo "XDG_STATE_HOME/log=$XDG_STATE_HOME/log"
echo "XDG_STATE_HOME=$XDG_STATE_HOME"

Additional program output to the terminal or log subsystem illustrating the issue

Oct 02 22:28:45 telcontar systemd[448300]: Starting check-xdg.service...
Oct 02 22:28:45 telcontar echo[448743]: XDG_CACHE_HOME=/home/test/.cache
Oct 02 22:28:45 telcontar echo[448745]: XDG_CONFIG_HOME=/home/test/.config
Oct 02 22:28:45 telcontar echo[448747]: XDG_STATE_HOME/log=/home/test/.local/state/log
Oct 02 22:28:45 telcontar echo[448749]: XDG_STATE_HOME=/home/test/.local/state
Oct 02 22:28:45 telcontar systemd[448300]: Finished check-xdg.service.

--- below is check-xdg.sh output
XDG_CACHE_HOME=/home/test/.local/var/cache
XDG_CONFIG_HOME=/home/test/.local/etc
XDG_STATE_HOME/log=/home/test/.local/var/state/log
XDG_STATE_HOME=/home/test/.local/var/state

[poettering]

environment.d only has an effect on the env block passed to services. It has no effect on the service manager itself. And that's unlikely to change. Since the unit file parser is done bythe service manager it hence doesn't care at all what you do in environment.d

Hence, this is expected. We could probably make this clearer in the docs, it currently says this:

Environment variables exported by the user manager (systemd --user instance started in the user@uid.service system service) apply to any services started by that manager. In particular, this may include services which run user shells. For example in the GNOME environment, the graphical terminal emulator runs as the gnome-terminal-server.service user unit, which in turn runs the user shell, so that shell will inherit environment variables exported by the user manager. For other instances of the shell, not launched by the user manager, the environment they inherit is defined by the program that starts them. Hint: in general, systemd.service(5) units contain programs launched by systemd, and systemd.scope(5) units contain programs launched by something else.

We probably should make very clear it only "applies" to the service in the sense that the env block is passed down to them and not in any other way. And we should probably make expressly clear it does not apply to the service manager itself.

[hseg]

On Mon, Oct 30, 2023 at 03:37:06PM -0700, Lennart Poettering wrote: environment.d only has an effect on the env block passed to services. It has no effect on the service manager itself. And that's unlikely to change. Since the unit file parser is done bythe service manager it hence doesn't care at all what you do in environment.d Hence, this is expected. We could probably make this clearer in the docs, it currently says this:

That is very unexpected to me -- in particular, I was expecting to be able to have services grab configuration from under `$XDG_CONFIG_HOME` and write persistence information under `$XDG_STATE_HOME`. (In particular, am writing a service for `pizauth` and would like it to write the output of `pizauth dump` to a state file on shutdown, cf <https://github.com/ltratt/pizauth#persistence>)

[poettering]

That is very unexpected to me -- in particular, I was expecting to be able to have services grab configuration from under $XDG_CONFIG_HOME and write persistence information under $XDG_STATE_HOME. (In particular, am writing a service for pizauth and would like it to write the output of pizauth dump to a state file on shutdown, cf https://github.com/ltratt/pizauth#persistence)

but why would set want to set these variables then?

[hseg]

On Wed, Nov 01, 2023 at 01:35:36AM -0700, Lennart Poettering wrote: > That is very unexpected to me -- in particular, I was expecting to be able to have services grab configuration from under `$XDG_CONFIG_HOME` and write persistence information under `$XDG_STATE_HOME`. (In particular, am writing a service for `pizauth` and would like it to write the output of `pizauth dump` to a state file on shutdown, cf <https://github.com/ltratt/pizauth#persistence>) but why would set want to *set* these variables then?

I believe my reproduction might have been confusing -- it was meant to illustrate the unexpected situation that the XDG settings set up in `~/.config/environment.d/` had been picked up by the login shell, but were not used in evaluating the specifiers for the units. In particular, I would expect `%C` in a user unit to always evaluate to the `environment.d` setting of `$XDG_CONFIG_HOME` (indeed, I'm not alone in this apparent misunderstanding, as [the Arch Linux wiki page](https://wiki.archlinux.org/title/Systemd/User#Environment_variables) on this also lists `environment.d` as being able to set the user unit's env block)

[hseg]

Reading through #29801 and noting that using pam_env to read
~/.pam_environment is deprecated, it seems the only relevant way to set up the
user service manager's environment is through a drop-in for user@.service?
This would have the bothersome implication that only the superuser is allowed to
set a user's service manager environment -- surely this should be something
that's up to the user?