jobstart() does not set $NVIM environment variable if /run/user/1000 is not accessible

[BKDevelop]

Problem

Description

This issue originated from the discussion in this bug report when using the plugin 'neogit'. However, I believe the root cause to be a bug in neovim itself.

The documentation states that vim.fn.jobstart(cmd) creates a subprocess with the appended environment variable $NVIM pointing to v:servername (the parent nvim instance). As far as I can tell, this works fine on native Linux and macOS. On WSL Distros, the env var appears to be unset:

Steps to reproduce

(0. Be on WSL)

1. Start nvim with minimal config

init.lua
---
vim.fn.jobstart("tail -f /dev/null")

2. Use a tool like htop to figure out the PID of the child process

3. Observe environment of the given process

$ cat /proc/<PID>/environ | tr '\0' '\n'

4. $NVIM is not set

I can reproduce this with the latest neovim stable and nightly builds. Personally, I use Ubuntu WSL, but my understanding from the comments in the original (neogit) issue is that this happens on several, if not all, WSL distros.

Please let me know if I can be of further assistance in debugging this issue!

Steps to reproduce

(0. Be on WSL)

1. Start nvim with minimal config

init.lua
---
vim.fn.jobstart("tail -f /dev/null")

2. Use a tool like htop to figure out the PID of the child process

3. Observe environment of the given process

$ cat /proc/<PID>/environ | tr '\0' '\n'

4. $NVIM is not set

I can reproduce this with the latest neovim stable and nightly builds. Personally, I use Ubuntu WSL, but my understanding from the comments in the original (neogit) issue is that this happens on several, if not all, WSL distros.

Please let me know if I can be of further assistance in debugging this issue!

Expected behavior

I expect $NVIM to be set to v:servername

Neovim version (nvim -v)

NVIM v0.10.0-dev-2663+gc1c6c1ee1

Vim (not Nvim) behaves the same?

Operating system/version

Ubuntu WSL

Terminal name/version

tmux

$TERM environment variable

screen-256color

Installation

system package manager

[BKDevelop]

Quick Update: I can reproduce this at least down to version 0.9.0. I ran into build issues with 0.8.3 and downwards. I won't be able to fix these build issues during the week due to time constraints. Cheers!

[BKDevelop]

I downloaded and tried some of the older precompiled binaries. It is always the same behavior. Could there be an issue with forkpty() on wsl? 🤔

Edit:
I wrote a little C program that a creates a subproccess with forkpty() and sets an env var. This works as expected. So I assume the bug is somewhere in neovims codebase.

[BKDevelop]

I tried this again on a different device running latest Windows 11. Everything works fine there.
I confirmed that WSL is running on both devices with latest Distro and Kernel versions, so it seems the issue has something to do with the windows version you run. Unfortunatly I cannot update the Win 10 device (corporate bs) to confirm this.

@zeertzjq I am not sure if we should close this issue now or if it makes sense to further investigate?

[dundargoc]

Technically we only support a subset over windows 10. Check https://github.com/neovim/neovim/blob/master/runtime%2Fdoc%2Fsupport.txt#L23-L25 to confirm which version you're using.

[BKDevelop]

I am on Win 10 build version "19045.4170", which should be supported. It still is surprising to me that the windows version has an effect on a linux binary running in WSL. I am probably missing something here, but I am out of ideas for reasonable next steps.

[dundargoc]

It still is surprising to me that the windows version has an effect on a linux binary running in WSL.

Fair, just wanted to make sure.

[Ramilito]

I got the same behaviour running on latest Windows 11 and latest nvim, latest WSL2 distro, latest WSL2 kernel. Found this issue through another Neogit issue: NeogitOrg/neogit#1124

However I got it working by turning off my boot systemd in .wslconfig!

[boot]
systemd=false

That's not really a long time solution though since I need systemd 😓

[BKDevelop]

I can confirm that this workaround does work. I agree that this is not a long term solution. My understanding is, that MS is planning to make systemd the default on WSL.

[Ramilito]

TLDR:
Permission issue for folder /run/user/1000

Found a better workaround and more info on what I believe is the actual issue.
As always, it seems to be a permission issue....running sudo -E -s nvim works as expected.

Workaround 1:
sudo -E -s nvim

Workaround 2 (preferred, I believe it's totally fine to take ownership of that folder, doesn't change after wsl --shutdown either):

sudo chown 1000:1000 /run/user/1000

What got me thinking in that direction was when comparing the difference in env vars for the child processes created by Neovim.

working without systemd
    NVIM=/tmp/nvim.ramilito/vgjzTj/nvim.3713.0

working with systemd running sudo -E -s nvim:
    NVIM=/run/user/1000//nvim.13916.0

not_working with systemd
    DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
    XDG_RUNTIME_DIR=/run/user/1000/

The permissions for /run/user/1000 do require root access as see when running ls -la:

drwx------ 2 root root 4096 Mar 27 22:15 .
drwxr-xr-x 4 root root 4096 Feb 14 16:49 ..
srwxr-xr-x 1 root root    0 Mar 27 22:15 nvim.21413.0

Found a issue for WSL here: microsoft/WSL#10498
This does indeed feel as a WSL issue and not a Neovim issue

[justinmk]

Permission issue for folder /run/user/1000

Did Nvim log anything in $NVIM_LOG_FILE ? We need to handle this case a bit better (e.g. show a more obvious error). #26058

[Ramilito]

The logs seem to be pretty good, wish I'd looked there in the beginning 😓 :

WRN 2024-03-27T22:14:46.817 ?.21077    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-03-27T22:14:58.030 ?.21381    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-03-27T22:21:37.619 ?.22125    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:46:38.755 ?.12916    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:46:46.384 ?.13369    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:47:39.578 ?.13435    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:48:50.429 ?.13549    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:48:56.549 ?.13579    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:48:59.432 ?.13920    server_start:163: Failed to start server: permission denied: /run/user/1000//
WRN 2024-04-01T10:49:15.539 ?.13978    server_start:163: Failed to start server: permission denied: /run/user/1000//