Environment

• Operating System: Linux
• Node Version: v22.10.0
• Nuxt Version: 3.13.2
• CLI Version: 3.15.0
• Nitro Version: 2.10.4
• Package Manager: pnpm@9.12.2
• Builder: -
• User Config: default
• Runtime Modules: -
• Build Modules: -

Reproduction

To truly recreate, you would have to install devenv and create a basic environment. Then run something like htop which gives the full process command, press F4 to filter and type nuxi you should see that when you start nuxt a bunch of node nuxi processes are created, but then when you quit some remain in D state and cannot be killed.

Alternatively, I managed to half recreate this by copying and pasting a newly initialized .devenv folder from my project into a freshly created nuxt project.

After a bit of digging, I realized if I just created a symlink in the .devenv folder I would get an error. Nuxt still runs in this case because it's not a true symlink to the nix store, but there's definitely something watching a folder it shouldn't.

 ERROR  [unhandledRejection] ELOOP: too many symbolic links encountered, stat '/home/alan/code/nuxt-zombie-watcher-issue/.devenv/test'

https://stackblitz.com/edit/github-6rzbve?file=README.md

Describe the bug

I'm not 100% sure what's going on, but I think something is trying to watch directories it shouldn't.

I'm on nixos and use devenv to create local dev environments and it creates a folder called .devenv. This contains all the state for the databases, etc, and symbolic links to executables in the nix store. I have this folder added to the .nuxtignore.

But I started noticing that I was running out of RAM when I shouldn't be after a while developing. I also started to get errors when stopping and re-running nuxt that I reached the system file limit for watchers (sometimes the warning was about files inside the .devenv folder, though I didn't notice at first). Odd.

I look at htop and see there are a bunch of unkillable (in D state) zombie nuxi processes. After much copying, pasting, and restarting, I narrow the problem down to the existence of the .devenv folder and the symlinks inside of it (see reproduction notes). I lifted it up the dev environment config/folders up a directory (not ideal) and the issue was gone.

Additional context

No response

Logs