Explain Linux inotify quota exhaustion when creating the network status watcher
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Start with crates/icp-app/src/network/managed/launcher.rs, especially wait_for_single_line_file and spawn_network_launcher, and trace native watcher construction before cmd.spawn(). Reproduce allocation failures by simulating native EMFILE and ENOSPC at watcher construction; verify diagnostics distinguish inotify instance quota, process FD limit, and watch quota, report useful limits, and spawn no child. Confirm normal startup and WSL watcher behavior remain intact.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
On 2026-10-11, Toko Miner's local network startup with published ICP CLI 1.6.0 failed with:
Error: failed to watch status directory
Caused by:
0: failed to watch file changes at path /tmp/.tmp6fJ6SO
1: Too many open files (os error 24)
The machine's fs.inotify.max_user_instances was 128, fs.inotify.max_user_watches was 1048576, and the invoking shell's soft/hard RLIMIT_NOFILE was 1048576. A separate small Python process reproduced inotify_init1(O_CLOEXEC) == -1 with errno EMFILE (24). This isolates exhausted per-user inotify instances rather than the shell's process descriptor limit. Editor/desktop processes held many watchers; there is no evidence that ICP leaks them. The watch-reference count is not a unique-instance count and is not used to establish the diagnosis.
Inspected released source: v1.6.0, commit 18435e1747162447fca231548b74d97e4cf48888, crates/icp-app/src/network/managed/launcher.rs, especially wait_for_single_line_file and spawn_network_launcher. The native notify::recommended_watcher is required alongside PollWatcher. Status watcher construction precedes cmd.spawn(), so this specific refusal occurs before spawning the launcher. The user-supplied log selected icp-cli-network-launcher v16.0.0-2026-09-18-03-28; launcher stdout/stderr were empty. No sibling source was used or modified.
Application impact: the build completed, then the explicit destructive local-reset flow deleted disposable local state before ICP startup hit this quota. We are adding an ephemeral allocation/watch probe before compilation and immediately before deletion, and documenting host remediation. The probe cannot reserve capacity across subsequent work. No host limit was changed or destructive reset retried during diagnosis. Application checkout: dragginzgame/toko-miner commit 3e53fb5b8963c126edf9d236f86c71c0a2f335cc, dirty local launcher fixes and concurrent lockfile edits, not a clean released-source qualification.
Reproduction on an already affected Linux host (does not allocate many watchers or alter limits):
cat /proc/sys/fs/inotify/max_user_instances
cat /proc/sys/fs/inotify/max_user_watches
ulimit -Sn
python3 - <<'PY'
import ctypes, os
libc = ctypes.CDLL(None, use_errno=True)
fd = libc.inotify_init1(os.O_CLOEXEC)
print('fd:', fd, 'errno:', ctypes.get_errno() if fd < 0 else 0)
if fd >= 0:
os.close(fd)
PY
Requested outcome: a Linux-specific resource diagnostic for native watcher allocation failures which names both possible EMFILE causes (per-user inotify instance quota and process FD limit), reports useful limits, and documents administrator remedies without changing host configuration or killing unrelated processes. ENOSPC should identify the watch quota separately. A lightweight upstream capacity-check surface would also help consumers admit destructive local workflows before deleting state. This is a diagnostics/documentation request, not a confirmed launcher defect or a request to introduce a silent polling fallback.
Acceptance: simulate native EMFILE and ENOSPC at watcher construction, assert accurate actionable diagnostics and no spawned child; keep normal startup and WSL watcher behaviour intact. Distinguish failed allocation before spawn from launcher crashes. Search of all open/closed issues for inotify, failed to watch, and Too many open files found no matching report.
Linux errno semantics: https://www.man7.org/linux/man-pages/man2/inotify_init.2.html
- Lingua principale
- Rust
- Stelle
- 115
- Fork
- 14
- Merge medio
- 21h 31m
- PR unite (30g)
- 28
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dfinity/icp-cli
-
Feature: `icp cycles buy` — buy cycles with a card for the current identity via an on-chain gatewayForse già presa @raymondk l’ha presa 6 giorni fa. Apertaenhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
sync plugin OOMs ("memory allocation of N bytes failed") when the target canister already has assetsAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
dfinity/icp-cli#703 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
question
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di dfinity/icp-cli
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
cmlarsen/writemorebetter#158 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
state:triage-needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
scanaislop/aislop#482 ·
I maintainer di solito rispondono entro 1 giorno
-
docs(skills): issue-first should reference an existing Linear ticket instead of filing a duplicateApertadocumentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno