Start user shells in proper PAM sessions

[K900]

Is your feature request related to a problem? Please describe. In NixOS, we rely on PAM to set up some important environment variables, including some related to locales, via pam_env.so. Right now WSL starts a single non-interactive shell with login -f to trigger the user systemd instance, but all the interactive shells are spawned bypassing PAM, and therefore not importing the environment variables.

Describe the solution you'd like WSL starts every interactive shell instance via login or a similar mechanism that runs PAM modules.

Describe alternatives you've considered Right now we're considering wrapping the user-selected shell in a script that updates the environment manually, but this will not be correct if any other PAM modules are involved.

Additional context The specific issue that led me to notice this was zsh failing to discover locales when spawned through WSL, as we require the LOCALE_ARCHIVE environment variable to be set for locale archives to be discovered.

[cerebrate]

Also an #8842 variant, I believe.

Right now WSL starts a single non-interactive shell with login -f to trigger the user systemd instance,

Huh. Is that what that's supposed to do? 'Cause on my system, at least, it doesn't, which is probably another race-condition-on-slower-systems issue similar to the one causing the issue described in the comments here.

I have to rely on systemd-machined / machinectl shell to get a working user systemd session and its appurtenances.

[HarbingerNight]

I have had success working around the wsl pam_env and systemctl --user commands issue by changing the wsl startup command parameters to launch a shell through sudo i.e.

wsl -u root sudo -u username zsh

[shmyer]

I had a similar issue related to WSL not using PAM. I had issues with Ubuntu 24.04. having a hard and soft limit on open files of 4096, which was too little for my Java app to compile using Maven: Too many open files

I tried raising the limits in /etc/security/limits.conf, but it didn't work and then I found this line in the config file: #This file sets the resource limits for the users logged in via PAM. This led me to this issue about WSL not using PAM.

@HarbingerNight your solution worked for me, thx. I changed the command line of my Windows Terminal according to your example and then the file limits got applied correctly in my terminal.

Edit: I still had issues with other WSL Integrations, for example when using IntelliJ IDEA's WSL Integration. I couldn't find a way there for modifying the command that is used for launching shells, so after a lot of fiddling around I found a permanent solution for all terminals/shells/integrations:

1. Allow your user to execute prlimit command with sudo without password. Add this to /etc/sudoers and replace your_usernamewith your username: your_username ALL=(ALL) NOPASSWD: /usr/bin/prlimit --nofile=* --pid * The wildcard for number of files can also be changed to a fixed value. For the pid however, it needs to be a wildcard.
2. Add this to your .profile: sudo /usr/bin/prlimit --nofile=65536 --pid $$; ulimit -n 65536 This will set the hard and soft open file limit to 65536 for the current shell process, which is inserted via the double dollar sign. This is why you need the wildcard for the pid in /etc/sudoers

Edit 2: Just found out, that my open file limit only was so low because my WSL kernel was outdated and didn't get updated properly. With the newer Kernel the open file limit is about 1M, which should be enough for anything... So first, maybe check your WSL kernel version :)