vim.system zombie process

[Ramilito]

Problem

I'm experiencing zombie process when exiting neovim even though detach is set to false.
pstree -p when neovim is still open:

pstree -p when neovim is closed:

Steps to reproduce

nvim --clean
:lua vim.system({ "kubectl", "proxy", "--port=0" }, {detach = false})
:q!

Expected behavior

I'm expecting the child process to be terminated when the parent is terminated if detached is set to false.
If I'm understanding the docs about detached correctly, I need to set it to true to make it live beyond the parents lifetime:

• detach: (boolean) If true, spawn the child process in a
detached state - this will make it a process group
leader, and will effectively enable the child to keep
running after the parent exits. Note that the child
process will still keep the parent's event loop alive
unless the parent process calls |uv.unref()| on the
child's process handle.

I have a workaround to manually kill it on VimLeavePre but I doubt that will run if neovim crashes:

  vim.api.nvim_create_autocmd("VimLeavePre", {
    callback = M.stop_kubectl_proxy(),
  })

Neovim version (nvim -v)

v0.11.0-dev

Vim (not Nvim) behaves the same?

I don't know

Operating system/version

Windows 11 (WSL)

Terminal name/version

Wezterm/20240203-110809-5046fc22

$TERM environment variable

xterm-256color

Installation

sudo apt-get install neovim

[lewis6991]

I'm not sure detach has the same semantics on windows. I'm not sure how WSL plays into this. One would think it should behave as Linux does.

I have a workaround to manually kill it on VimLeavePre but I doubt that will run if neovim crashes:

Even with the correct behaviour of detach, there's little we can do to ensure all processes are killed in the event of a crash.

[Ramilito]

I'm not sure detach has the same semantics on windows. I'm not sure how WSL plays into this. One would think it should behave as Linux does.

Yeah, just verified in OSX and it also leaves the process alive after neovim shutsdown.

Even with the correct behaviour of detach, there's little we can do to ensure all processes are killed in the event of a crash.

I understand, would be nice to handle it in the normal shutdown though.

[lewis6991]

Yeah, just verified in OSX and it also leaves the process alive after neovim shutsdown.

That's surprising. My understanding was the detach=false would always kill all immediate child jobs of Nvim when it is closed (even in a crash). This is supposed to be handled by the OS.

Can you test with a simpler process? { "kubectl", "proxy", "--port=0" } may be launching its own child processes, which Nvim cannot manage. If that's the case, then you may actually need deatch=true.

[gpanders]

Yeah, just verified in OSX and it also leaves the process alive after neovim shutsdown.

The OS will not automatically kill an orphaned process. It is reparented to the init process which waits for the orphaned process to exit. If a child process is connected to a pipe from the parent process (as is usually the case for an LSP server), then the child process will exit when its parent dies because the pipe is closed. But if this isn’t the case then the child will happily run forever until it’s told to stop.

This is the case for regular processes anyway, I am not sure what magic libuv does behind the curtain though.