WSL related environment variables not sourced if distribution is started without command

[meyayl]

As the title says: the file ~/.systemd-env is only sourced, if the wsl distribution started with a command, e.g.:

$ wsl -d Ubuntu-20.04 command

Though, they the file is not sourced, if it is started like this wsl -d Ubuntu-20.04. This is due to exec /usr/bin/nsenter -t "$SYSTEMD_PID" -a /bin/login -p -f "$SUDO_USER" beeing called if no command is provided.

[saltyming]

We need to check DamionGans#33 for this issue. The problem is that they just deleted that part simply in fe4562f
I will test it when new LTSC comes (in a few days).

[meyayl]

Now that makes sense. The command print the variables from ~/.systemd-env as ENV=VAR and therefor statisfy login [-p] [-h host] [username] [ENV=VAR...]

I just checked what the line does with cat ~/.systemd-env | xargs printf ' %q'. So restoring the original line should do the trick.

[meyayl]

I just added the code snippet into the enter script. I hadn't notived that all ENV=VAR pairs are single quoted. As a result they appears single quoted in the environment section.

[meyayl]

Update:
I guess I figured out why the snippet was removed: values with spaces (like the path) are splited and end up in their own environment variables starting with L(\d{1,2}), as in L1, .., L12, which is messy and undesired.

I assume /bin/login requires some sort of escaping to retain space characters in values or another wizardry I haven't come up with yet.

None of those approaches works:

• modify the sed syntax to remove the double quotes in the values written to ~/.systemd-env -> same problem
• write ~/.systemd-env to /etc/environments in enter script -> still not all variables are used
• use the snipped from the removed commit in enter script -> same problem
• use $(cat "${USER_HOME}/.systemd-env" | xargs -d '\n') instead -> same problem

[saltyming]

Update: I guess I figured out why the snippet was removed: values with spaces (like the path) are splited and end up in their own environment variables starting with L(\d{1,2}), as in L1, .., L12, which is messy and undesired.

I assume /bin/login requires some sort of escaping to retain space characters in values or another wizardry I haven't come up with yet.

None of those approaches works:

• modify the sed syntax to remove the double quotes in the values written to ~/.systemd-env -> same problem
• write ~/.systemd-env to /etc/environments in enter script -> still not all variables are used
• use the snipped from the removed commit in enter script -> same problem
• use $(cat "${USER_HOME}/.systemd-env" | xargs -d '\n') instead -> same problem

Can you try bash -c '/bin/login -p -f "$SUDO_USER" $([ -f "$USER_HOME/.systemd-env" ] && /bin/cat "$USER_HOME/.systemd-env" | xargs -d '\''\n'\'')'?

[meyayl]

Basicly this is ist a different set of delimiters. Sure I can try them as soon as I remember/find how to skip the "entrypoint script" for the wsl distro. I messed smth up while testing it. Probably forget a quote somewhere -> pebkac...

Update: wsl --distribution Ubuntu-20.04 -e bash --norc, now i can fix whatever I messed up. I missed that you wrapped your line in bash -c '...'

[meyayl]

No breakage on:

exec /usr/bin/nsenter -t "$SYSTEMD_PID" -a \
   /bin/bash -c '/bin/login -p -f "$SUDO_USER" $([ -f "$USER_HOME/.systemd-env" ] && /bin/cat "$USER_HOME/.systemd-env" | xargs -d '\''\n'\'')'

I did a git reset --hard to have a clean starting point, though seems the original line and the new line yield the same result.

[meyayl]

I just modified the start script to add an additional variable that is not passed in by the /etc/sudoers.d configuration.

The additional environment variable IS present. It just doesn't seem to work for the XDG_RUNTIME_DIR variable that way.
The variable is present if I start the distro using wsl -d Ubuntu-20.04 env and has a different value when using wsl -d Ubuntu-20.04 and running env on the command line, even though the correct value is in ~/.settings-env.

[saltyming]

I just modified the start script to add an additional variable that is not passed in by the /etc/sudoers.d configuration.

The additional environment variable IS present. It just doesn't seem to work for the XDG_RUNTIME_DIR variable that way.
The variable is present if I start the distro using wsl -d Ubuntu-20.04 env and has a different value when using wsl -d Ubuntu-20.04 and running env on the command line, even though the correct value is in ~/.settings-env.

Did you added DISPLAY and XAUTHORITY variables to pass?

[saltyming]

I just modified the start script to add an additional variable that is not passed in by the /etc/sudoers.d configuration.

The additional environment variable IS present. It just doesn't seem to work for the XDG_RUNTIME_DIR variable that way.
The variable is present if I start the distro using wsl -d Ubuntu-20.04 env and has a different value when using wsl -d Ubuntu-20.04 and running env on the command line, even though the correct value is in ~/.settings-env.

Because that value is set by pam_systemd which cannot be used with current env process (Login via /bin/login and load additional env values)

[meyayl]

Did you added DISPLAY and XAUTHORITY variables to pass?

I added DISPLAY to the sudoers profile, but not XAUTHORITY, as it is neither required for WSLg, nor for my xrdp based custom image. It is only rendered into the suoderes profile, if --no-wslg is not specified.

With WSLg the wsl system distribution, provides Wayland and exposes the .x11-unix/X0 unix daemon socket and the /dev/dxg vgpu (used by mesa >v21.0 automaticly) to the wsl user distribution . Each user distribution has its own sibling system distribution. It also seem to be responsible to inject the required set of variables into the user distribution. Even with the "wrong" XDG_RUNTIME_DIR, running x11 applications works just fine and the application window is rendered on the windows host.

I haven't tested to set the DISPLAY to "nameserver:screen" and forward X11 output to a x11 server running on the Windows host,

Because that value is set by pam_systemd which cannot be used with current env process (Login via /bin/login and load additional env values)

Sounds reasonable.

Offtopic:

Btw. I feel adding the start script to /etc/bash.bashrc does make things unnecessarily complicated. If BASH_ENV is set to /etc/profile, the start script could be installed into /etc/profile.d/ and simply uninstalled by deleting the file. At the same time this would faciliate a way to add custom user defined start scripts.

[saltyming]

Did you added DISPLAY and XAUTHORITY variables to pass?

I added DISPLAY to the sudoers profile, but not XAUTHORITY, as it is neither required for WSLg, nor for my xrdp based custom image. It is only rendered into the suoderes profile, if --no-wslg is not specified.

With WSLg the wsl system distribution, provides Wayland and exposes the .x11-unix/X0 unix daemon socket and the /dev/dxg vgpu (used by mesa >v21.0 automaticly) to the wsl user distribution . Each user distribution has its own sibling system distribution. It also seem to be responsible to inject the required set of variables into the user distribution. Even with the "wrong" XDG_RUNTIME_DIR, running x11 applications works just fine and the application window is rendered on the windows host.

I haven't tested to set the DISPLAY to "nameserver:screen" and forward X11 output to a x11 server running on the Windows host,

Because that value is set by pam_systemd which cannot be used with current env process (Login via /bin/login and load additional env values)

Sounds reasonable.

Offtopic:

Btw. I feel adding the start script to /etc/bash.bashrc does make things unnecessarily complicated. If BASH_ENV is set to /etc/profile, the start script could be installed into /etc/profile.d/ and simply uninstalled by deleting the file. At the same time this would faciliate a way to add custom user defined start scripts.

Do whatever you want.

[meyayl]

This issue can be closed. We discussed in depth about the topic and I come to understand that it's not realy an issue, but rather the way things under the hood work.