nsenter: failed to parse pid: '-p' on a previously working installation

[harryaskham]

Similar issue to e.g. #67 except I have only found records of this issue happening on fresh installations, with advice to reinstall with a fixed installer. This started happening on a NixOS WSL installation that's been working fine since 2022-11-06.

The system follows unstable. I had a few-days-old nixos-rebuild switch --upgrade which I discounted as the culprit due to it working fine since, but WSL had been up since and hadn't had to boot until now. Rolling back has fixed it (while I was writing this up - leaving this as I'd have found it useful when searching the issue), but given this system can't --upgrade without issue I'll reinstall from a newer base.

---

On booting Win11 and opening a WSL term, the first session hangs on systemd launch:

Copying /usr/share/applications
Copying /usr/share/icons
warning: not applying UID change of user ‘harry’ (1001 -> 1000) in /etc/passwd
setting up /etc...
setting up /bin...
Starting systemd...

This is not new and has been happening since system installation. Usually the second session boots.
Now though opening the second+ session gives:

nsenter: failed to parse pid: '-p'

[process exited with code 1 (0x00000001)]

No amount of Win11 rebooting or wsl --shutdown fixes this.

I can reach a shell via:

PS C:\Users\harry> wsl -d nixos -e sh
sh-5.2# /nix/var/nix/profiles/system/activate
...
sh-5.2# source /etc/set-environment
...
root@nixos:/mnt/c/Users/harry/ >

and if I then run

root@nixos:/mnt/c/Users/harry/ > echo -n "1" >> /var/run/systemd.pid

I can open a regular WSL session and it'll log in fine. Ultimately this let me roll back a couple of generations before the --upgrade.

journalctl -b shows the following on the successful session login:

Aug 27 08:48:10 rog-win11 systemd[593]: Failed to attach 593 to compat systemd cgroup /user.slice/user-1001.slice/user@1001.service/init.scope: Permission denied
Aug 27 08:48:10 rog-win11 systemd[1]: Incoming private connection from unprivileged client, refusing: No data available

I don't have any journal entries before the sh fallback session (i.e. the nsenter -p failed attempts).

[SuperSandro2000]

Are you using native systemd?

[harryaskham]

I hadn't touched anything systemd-related myself, either in WSL2 or NixOS, but I don't know what's happening transitively. So however WSL would have been configured late 2022 is at least how the system started out. I've been running tailscale as tailscaled.service in it for some time i.e. before the current systemd setup in NixOS-WSL.

I get a 160K line nix-diff of the generations either side of the nixos-switch --upgrade - amongst other things, it upgrades systemd{-minimal{-libs}} from 255.6 to 256.4. Not familiar enough with systemd to know whether this counts as native.

[SuperSandro2000]

https://learn.microsoft.com/en-us/windows/wsl/systemd#how-to-enable-systemd

https://github.com/nix-community/NixOS-WSL/blob/main/modules/systemd/default.nix#L10

That's what we support going forward. The syschdemd way is eventually going away.

[harryaskham]

Got you, thanks for the pointers. I did try to manually edit this into /etc/wsl.conf but found it's actually managed by NixOS; in any case I'm too far behind to use this, The option wsl.nativeSystemd' does not exist.`. I might be able to update the NixOS-WSL machinery separately to the otherwise breaking upgrade that borks the system, but I'll probably just clean install at this point.

[nzbr]

There is a good chance you will be able to rescue it by doin the things in the Migrating from 22.05 releases section on the 23.05.5 release. By doing that you will add this repo as a channel, so you will get the latest NixOS-WSL code, not actually the release from back then. It just happens to be the one where we changed the delivery method

[harryaskham]

Oh, perfect, that's exactly what I needed. The 23.05 upgrade process fixed the issue without needing a WSL-level reinstall. Thanks!