Begging help for envfs race condition make the kernel fail into uninterrupted system call

Hi community,

I’m currently facing a problem in NixOS and I don’t know how to deal with it.

Occasionally, seemingly at random, a process (specifically in Chromium) gets left in a D state and stops responding entirely. When this happens, my machine starts to misbehave, and some functionalities just hang after opening, and zsh also joined the hang party.

Luckily, I can still access the shell using a workaround to reboot the machine. After the reboot, the log shows:

request_wait_answer [fuse]
__fuse_simple_request [fuse]
fuse_dentry_revalidate [fuse]
__lookup_slow → walk_component → path_lookupat
filename_lookup → vfs_statx → __do_sys_newstat 

I’m not sure how to resolve this. An AI suggested it might be a race condition bug or something related to envfs, but I don’t have experience creating workarounds while waiting for a fix from upstream.

**Currently, this is happening more often, and I haven’t been able to work properly for days.

Please help! Thank you veriy much!**

What’s your PATH set to? (And I assume you are in fact using envfs, and it wasn’t just the AI hallucinating that you are?)

Here is my PATH: /home/hoang/.local/bin:/run/wrappers/bin:/home/hoang/.nix-profile/bin:/nix/profile/bin:/home/hoang/.local/state/nix/profile/bin:/etc/profiles/per-user/hoang/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin . I added the ~/.local/bin to use claude code, everything else is the default.
And the hang usually happen when I open a vscode (or after open it for a while).

I asked the AI to help me fix but it is unreliable, the only thing I knew from the shutdown log was: my /bin failed to umount (which is envfs) and process pet was holding the D flag.

Well, that probably rules out that theory. I was thinking /bin or /usr/bin might be in PATH for some reason, causing envfs to be doing fs lookups inside itself. I do think it’s very likely related to envfs, though. There is some possibility vscode is messing with PATH somewhere, too.

I think I identified the cause. The condition to make the D state happen is opening vscode, but I straced it a lot but was still hopeless.
Then I tried to launch claude code and straced it too. An unusual vfork happened. it called a bunch of things and then ran execve a ghost version of vscode in /nix/store (older than my current vscode version now, but still there because I never ran the clean command). Things went wrong from then on, and ultimately it spawned some extensions (I think it is from the Python extension) and finally end up with a D state on process pet (well, the cause is a call on the FUSE filesystem at /bin, I didn’t know what triggered it).
After that, I uninstalled claude code and reinstalled it fresh and that issue was gone. I also cant find the syscall that called vscode directly on the /nix/store again, It seems I installed something weird before and something resolve the symlink to /nix/store and called the ghost version.

1 Like