Jak opravit chybu „ENOSPC: Dosažen systémový limit pro hlídače souborů“ v Linuxu

Pokud se vývojový nástroj pro Linux náhle zastaví s ENOSPC: System limit for number of file watchers reached, může být zpráva zavádějící. ENOSPCObvykle se zní jako „na zařízení nezbývá místo“, ale v této konkrétní cestě to často neznamená, že je disk plný. inotify_add_watch()Manuál pro Linux uvádí, ENOSPCže vráceno může být, když je dosaženo limitu na uživatele u hlídek inotify nebo když jádro nemůže alokovat požadovaný zdroj. Toto rozlišení je důležité, protože smazání souborů nemusí problém nijak vyřešit.

Tato příručka nejprve provede diagnostikou, poté nejméně rušivou opravou a nakonec trvalou konfigurací. Příkazy platí pro systémy Linux, které používají rozhraní inotify jádra , jež umožňuje aplikacím monitorovat změny v souborech a adresářích. Často se na něj spoléhají vývojové servery, IDE, synchronizační klienti, testovací spouštěče a nástroje pro sestavení.

Dokumentace manuálových stránek Linuxu byla zkontrolována 13. září 2026. Klíčovými referencemi jsou aktuální manuál inotify_add_watch(2) a přehled inotify(7) .

Co potřebujete před jakoukoli změnou

Potřebujete terminál a pro změnu parametrů jádra účet, který umí používat sudo. Před zastavením vývojových serverů nebo editorů uložte neuloženou práci. Všimněte si také, kde je spuštěn příkaz, který selhal: přímo v Linuxu, ve virtuálním počítači, ve WSL nebo uvnitř kontejneru. Kontejner může sdílet nastavení jádra se svým hostitelem a nemusí mít povoleno měnit sysctl na úrovni hostitele.

Nezačínejte kopírováním příliš velkého limitu sledujících procesů z příspěvku na fóru. Nejprve zkontrolujte aktuální nastavení a zjistěte, zda jej nespotřebovávají zastaralé nebo duplicitní procesy sledujících.

Krok 1: Potvrďte, že se jedná o chybu sledujícího inotify

Spusťte příkaz, který selhal, a přečtěte si celou chybu. Mezi typické spouštěče patří spuštění vývojového serveru JavaScriptu, testovacího spouštěče pro sledování souborů nebo pracovního prostoru IDE, který obsahuje velmi rozsáhlý adresářový strom. Důležitá fráze je „byl dosažen systémový limit pro počet hlídačů souborů“.

Pokud se chyba vyskytuje ENOSPCpři zápisu souboru, zkontrolujte kapacitu disku a dostupnost inodů pomocí příkazů, jako například df -ha df -i. Tento článek se konkrétně týká formy inotify watcher-limit příkazu ENOSPC.

Krok 2: Přečtěte si aktuální limity funkce inotify

Linux zpřístupňuje omezení inotify v /proc/sys/fs/inotify/. Watch je jeden monitorovaný objekt souborového systému v rámci instance inotify. Dokumentace jádra rozlišuje tři ovládací prvky:

• max_user_watches: maximální počet sledování pro jedno skutečné uživatelské ID.
• max_user_instances: maximální počet instancí inotify pro jedno skutečné ID uživatele.
• max_queued_events: maximální počet událostí zařazených do fronty pro instanci inotify.

Zkontrolujte je beze změn:

sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances
sysctl fs.inotify.max_queued_events

První hodnotu si můžete také přečíst přímo:

cat /proc/sys/fs/inotify/max_user_watches

Nezaměňujte fs.inotify.max_user_watchess fs.epoll.max_user_watches. Jsou to různé mechanismy jádra. V případě této chyby se obvykle zajímáte o cestu inotify.

Krok 3: Hledejte procesy, které spotřebovávají mnoho hodin sledování

Jádro zpřístupňuje informace o sledování inotify v /proc/<pid>/fdinfozáznamech každého procesu. Dokumentace k proc_pid_fdinfo(5) uvádí, že řádky začínající na inotifypopisují monitorované soubory nebo adresáře.

Pro rychlou kontrolu tento příkaz zobrazuje řádky inotify, které vám vaše oprávnění umožňují číst:

sudo grep -H '^inotify' /proc/[0-9]*/fdinfo/* 2>/dev/null | head -n 50

Pro užitečnější odhad pro každý proces u aktuálního uživatele použijte:

uid=$(id -u)
for p in /proc/[0-9]*; do
  [ "$(awk '/^Uid:/{print $2}' "$p/status" 2>/dev/null)" = "$uid" ] || continue
  n=$(grep -h '^inotify' "$p"/fdinfo/* 2>/dev/null | wc -l)
  [ "$n" -gt 0 ] || continue
  printf '%s\t%s\t%s\n' "${p##*/}" "$n" \
    "$(tr '\0' ' ' < "$p/cmdline" 2>/dev/null | cut -c1-80)"
done | sort -k2,2nr | head

Tento výstup považujte spíše za diagnostický odhad než za dokonalé zúčtování, zejména pokud jsou sdíleny deskriptory souborů. Jeho účelem je odhalit zjevné viníky, jako je několik starých vývojových serverů, duplicitní instance IDE nebo více sledujících serverů nad stejným velkým repozitářem.

Krok 4: Zastavte zastaralé hlídače a zkuste to znovu před zvýšením limitu

Pokud najdete vývojové servery nebo nástroje, které již nepotřebujete, nejprve je normálně zavřete. Restartování editoru nebo vývojového serveru s velkým počtem sledovacích zařízení může také uvolnit sledovací zařízení zanechaná dlouho běžící relací. Vyhněte se širokému killallpříkazu, pokud přesně nevíte, co zastaví.

Po ukončení podezřelých procesů spusťte původní příkaz znovu. Pokud nyní funguje, možná nebudete jádro vůbec měnit. Opakované vyčerpání však naznačuje, že pracovní zátěž skutečně potřebuje více hlídání nebo že nástroj sleduje příliš mnoho procesů.

Krok 5: Dočasně otestujte vyšší hodnotu max_user_watches

Změna sysctl za běhu je užitečná, protože ji můžete otestovat předtím, než ji nastavíte jako trvalou. Nejprve si zaznamenejte aktuální hodnotu:

sysctl fs.inotify.max_user_watches

Pak zvolte hodnotu, která je dostatečně velká pro pozorovanou pracovní zátěž. Například pokud se záměrně rozhodnete otestovat 524 288 hodin:

sudo sysctl fs.inotify.max_user_watches=524288

Toto je příkladová hodnota, nikoli univerzální doporučení . Limity inotify existují pro omezenou spotřebu zdrojů jádra, takže jejich zvýšení bez pochopení pracovní zátěže není bezplatné. Lepším přístupem je zvýšit počet měřených kroků, zkusit aplikaci znovu a zastavit ji, jakmile budete mít dostatečný prostor.

Manuál k sysctl (8) dokumentuje čtení a změnu parametrů jádra za běhu.

Krok 6: Zajistěte, aby testovaná hodnota byla trvalá

Pokud dočasná změna problém vyřeší a hodnota je pro váš počítač vhodná, uložte ji do konfiguračního souboru sysctl. V distribucích založených na systemd může lokální správce umístit konfiguraci do souboru /etc/sysctl.d/*.conf. Dokumentace k systemd sysctl.d vysvětluje, že soubory v souboru /etc/sysctl.d/jsou určeny pro konfiguraci lokálního správce a jsou zpracovávány v pořadí podle názvu souboru.

Vytvořte si vyhrazený soubor, místo abyste změnu uchovávali mezi nesouvisejícími nastaveními:

sudo nano /etc/sysctl.d/99-inotify.conf

Přidejte hodnotu, kterou jste již otestovali:

fs.inotify.max_user_watches=524288

Pokud váš systém nepoužívá tok sysctl.d ze systemd, prostudujte si dokumentaci k vaší distribuci před výběrem trvalého umístění konfigurace.

Krok 7: Použití trvalé konfigurace a její ověření

Můžete restartovat, ale to obvykle není nutné. Na systémech s sysctlnástrojem procps použijte konfiguraci systému pomocí:

sudo sysctl --system

Pak ověřte aktivní hodnotu:

sysctl fs.inotify.max_user_watches

Aktivní hodnota by měla odpovídat zamýšlenému nastavení. Pokud ne, zkontrolujte výstup a vyhledejte sysctl --systemnovější konfigurační soubor, který vaši položku přepíše. Pravidla pojmenování sysctl.d jsou důležitá, protože novější názvy souborů mohou mít přednost, pokud je stejná proměnná přiřazena vícekrát.

Krok 8: Restartujte aplikaci a omezte zbytečný rozsah sledování

Spusťte aplikaci, která původně selhala. Pokud se spustí normálně, oprava na straně jádra funguje. Pokud je využití sledování neočekávaně vysoké, nekončete tam. Nakonfigurujte aplikaci, kde je to podporováno, tak, aby vyloučila adresáře, které nevyžadují živé monitorování, jako je generovaný výstup sestavení, mezipaměti, velké protokoly, stromy dodavatelů nebo adresáře závislostí.

Snížení rozsahu sledování je často nejlepším dlouhodobým řešením, protože snižuje využití zdrojů jádra a omezuje zpracování událostí souborů. Některé nástroje nabízejí dotazování jako záložní řešení, ale dotazování může zvýšit aktivitu CPU a I/O, takže je obvykle lepší s ním zacházet jako s možností kompatibility než jako s prvním řešením.

Co když se chyba stále zobrazuje?

Zkontrolujte, zda je max_user_instances skutečným omezením.

max_user_instancesomezuje počet instancí inotify na jedno skutečné ID uživatele. Režim selhání je však jiný: aktuální manuál inotify_init(2) dokumentuje, EMFILEkdy je dosaženo limitu inotify-instance na uživatele. To znamená, že přesná zpráva hlídače ENOSPC přímo odkazuje na hlídače nebo alokaci zdrojů, nikoli automaticky na limit instance.

Nesahejte nejprve po ulimit -n

ulimit -nřídí limit deskriptorů otevřených souborů procesu. Deskriptory souborů souvisí s instancemi inotify, ale jedna instance inotify může obsahovat mnoho sledujících instancí. Zvýšení limitu otevřených souborů proto není přímým řešením pro inotify_add_watch()ENOSPC způsobený max_user_watches.

Kontejnery nemusí být schopny změnit tento sysctl.

Docker dokumentuje, že ne každý sysctl má jmenný prostor a že nepodporuje změny kontejnerových sysctl, které by mohly modifikovat hostitelský systém. Pokud selhávající úloha běží v Dockeru a fs.inotify.max_user_watchesje řízena jádrem hostitele, proveďte změnu na příslušném hostiteli nebo virtuálním počítači, místo abyste ji vynucovali z neprivilegovaného kontejneru. Viz dokumentace k běhovému sysctl v Dockeru .

Časté chyby, kterým se vyhnout

• Za předpokladu, že ENOSPC vždy znamená plný disk. Systémové volání inotify explicitně používá ENOSPC pro selhání watch-limit/resource.
• Změna max_queued_events namísto max_user_watches. Limit fronty řídí čekající události, nikoli počet objektů souborového systému, které může uživatel sledovat.
• Nastavení enormní hodnoty bez měření. Existují limity Inotify pro omezení využití zdrojů jádra; zvyšujte je záměrně.
• Provedení trvalé změny před jejím otestováním. Dočasná sysctlzměna se snáze ověří a vrátí zpět.
• Zapomínání na duplicitní procesy sledujících. Stejný fond pro jednotlivé uživatele může využívat několik editorů, vývojářských serverů nebo synchronizačních nástrojů.
• Používání sudo echo value > /proc/...a očekávání sudo k pokrytí přesměrování. Shell se provede >před sudospuštěním. Použijte sudo sysctl ...místo toho.

Rychlý diagnostický kontrolní seznam

Primární dokumentace

Zde popsané chování pochází z dokumentace uživatelského rozhraní linuxového jádra, dokumentace souborového systému proc, dokumentace sysctl.d v systemd a dokumentace běhového prostředí Dockeru. Nejdůležitější podrobnosti naleznete v inotify(7) , inotify_add_watch(2) , proc_pid_fdinfo(5) a sysctl.d(5) .