Skip to content
Cade's Dotfiles

Python setup waits in NFS locking

Page source

Source: Troubleshooting reference

Symptom: Python setup stops at Preparing the refreshable Google MCP transport; uv run --locked --script ... --check-runtime stays idle.

Root cause: the script environment cache lives under a shared NFS tool root. uv locks its environment before installing dependencies, and an NFS lock request can wait in the kernel even though no local process holds the lock. On Blackwell, observed on 2026-10-12, the cache was on NFSv3 and a uv worker’s wait channel was nlmclnt_wait. The same locked check completed with its cache on the host’s ext4 state volume.

Confirm on Linux: select the affected uv PID and inspect its actual cache and worker threads:

Terminal window
pgrep -af 'uv.*google-mcp.py'
findmnt -T "$UV_CACHE_DIR" -o TARGET,FSTYPE
ps -L -p UV_PID -o pid,tid,stat,wchan:30,args

If the calling shell does not have UV_CACHE_DIR, read only that variable from /proc/UV_PID/environ; do not print the complete environment.

Fix: configure a persistent host-local DF_STATE_ROOT with bash ~/dotfiles/install/host.sh configure. Current installers and managed Google/Gemini launchers then use $DF_STATE_ROOT/uv/cache. An explicit UV_CACHE_DIR still wins. Stop the stuck bootstrap in its terminal before starting another; with Blackwell’s existing local state configuration, the one-invocation recovery is:

Terminal window
UV_CACHE_DIR="$DF_STATE_ROOT/uv/cache" ~/dotfiles/bootstrap.sh upgrade

The first run populates a fresh cache. Existing processes retain the old path; do not delete a lock file or disable locking. This change does not relocate installed Python/tool environments or fix project environments stored on NFS. Sources: uv cache safety, _runtime-paths.sh, python.sh, and package cache defaults.