[systemd-devel] "systemd-path systemd-search-user-unit" does not match reality

[Vladimir Panteleev]

On Thu, 25 Jul 2024 at 11:59, Mantas Mikulėnas <grawity at gmail.com> wrote:
> The paths for user units and other user configuration depend on your XDG_{CONFIG,DATA}_{DIRS,HOME} environment variables.
>
> Since systemd-search-user-unit is running as part of your interactive session (and under your interactive shell) whereas systemd --user itself is not, they will likely have different lists of environment variables, especially if you have Nix set up a custom XDG_* through /etc/profile or similar.

Thank you for that pointer!

There is indeed an /etc/profile script which sets XDG_DATA_DIRS.

I was confused because I expected "systemd-path" to work like
"systemctl show-environment", i.e. fetch the variables from the
daemon.

I think a note in the systemd-path man page that it uses the invoker's
environment and not the daemon's environment would be a useful
addition.

> While systemd --user has a few ways to push environment variables into the services it starts, those all happen after initialization; there's no good equivalent for providing envvars for systemd itself. You would need to `sudo systemctl edit user@$UID` and add some [Service] Environment= definitions there.

This seems to work:

cat > ~/.config/systemd/user.conf <<EOF
[Manager]
ManagerEnvironment="XDG_DATA_DIRS=%h/.nix-profile/share"
EOF

By the way, to test this, I put together the following incantation
which I thought would show the effective search paths from the
daemon's POV:

( mapfile -t -d '' vars < <(sudo cat /proc/"$(pgrep -f -u $UID
'/usr/lib/systemd/systemd --user')"/environ) && env -i "${vars[@]}"
systemd-path systemd-search-user-unit | tr : '\n' )

However, again to my confusion, the systemd process's environment
block does not necessarily reflect the paths that will be looked up.
It turns out that setting things in ManagerEnvironment does not
necessarily map to a setenv call. (I think this, also, would be useful
to mention in the documentation of ManagerEnvironment.)

So, I don't know of any reliable way to inspect the real systemd unit
search path, but at least I solved my original problem!