Slik fikser du «ENOSPC: Systemgrense for filovervåkere nådd» i Linux

Hvis et Linux-utviklingsverktøy plutselig stopper med ENOSPC: System limit for number of file watchers reached, kan meldingen være misvisende. ENOSPCleses vanligvis som «ingen plass igjen på enheten», men i denne spesifikke banen betyr det ofte ikke at disken din er full. Linux- inotify_add_watch()manualen sier ENOSPCat kan returneres når grensen per bruker for inotify-overvåkninger er nådd, eller når kjernen ikke kan tildele en nødvendig ressurs. Denne forskjellen er viktig fordi sletting av filer kanskje ikke gjør noe for å løse problemet.

Denne veiledningen går først gjennom diagnosen, deretter den minst forstyrrende løsningen, og til slutt en vedvarende konfigurasjon. Kommandoene gjelder for Linux-systemer som bruker kjernens inotify- grensesnitt, som lar applikasjoner overvåke filer og mapper for endringer. Utviklingsservere, IDE-er, synkroniseringsklienter, testkjørere og byggeverktøy er ofte avhengige av det.

Dokumentasjonen for Linux man-pages ble sjekket 13. september 2026. De viktigste referansene er den nåværende inotify_add_watch(2) manualen og inotify(7) oversikten .

Det du trenger før du endrer noe

Du trenger en terminal, og for å endre kjerneparametere, en konto som kan bruke sudo. Lagre ulagret arbeid før du stopper utviklingsservere eller editorer. Merk også hvor den feilende kommandoen kjører: direkte på Linux, i en virtuell maskin, i WSL eller inne i en container. En container kan dele kjerneinnstillinger med verten sin og har kanskje ikke lov til å endre en sysctl på vertsnivå.

Ikke begynn med å kopiere en veldig stor overvåkingsgrense fra et foruminnlegg. Sjekk først den nåværende innstillingen din og identifiser om foreldede eller dupliserte overvåkingsprosesser bruker den.

Trinn 1: Bekreft at dette er inotify watcher-feilen

Kjør kommandoen som mislyktes og les hele feilen. Typiske utløsere inkluderer å starte en JavaScript-utviklingsserver, en testkjører for filovervåking eller et IDE-arbeidsområde som inneholder et veldig stort katalogtre. Den viktige frasen er «systemgrense for antall filovervåkere nådd».

Hvis feilen i stedet oppstår ENOSPCunder skriving av en fil, sjekk diskkapasitet og inode-tilgjengelighet med kommandoer som df -hog df -i. Denne artikkelen handler spesifikt om inotify watcher-limit-formen av ENOSPC.

Trinn 2: Les de gjeldende inotify-grensene

Linux eksponerer inotify-grenser under /proc/sys/fs/inotify/. En watch er et overvåket filsystemobjekt i en inotify-instans. Kjernedokumentasjonen skiller mellom tre kontroller:

• max_user_watches: maksimalt antall overvåkninger for én ekte bruker-ID.
• max_user_instances: maksimalt antall inotify-forekomster for én ekte bruker-ID.
• max_queued_events: maksimalt antall hendelser i kø for en inotify-instans.

Sjekk dem uten å endre noe:

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

Du kan også lese den første verdien direkte:

cat /proc/sys/fs/inotify/max_user_watches

Ikke forveksle fs.inotify.max_user_watchesmed fs.epoll.max_user_watches. De er forskjellige kjernemekanismer. For denne feilen bryr du deg vanligvis om inotify-banen.

Trinn 3: Se etter prosesser som bruker mange overvåkninger

Kjernen eksponerer inotify-overvåkingsinformasjon i hver prosess' /proc/<pid>/fdinfooppføringer. Dokumentasjonen proc_pid_fdinfo(5) oppgir at linjer som begynner med inotifybeskriver overvåkede filer eller mapper.

For en rask inspeksjon viser denne kommandoen inotify-linjer som tillatelsene dine tillater deg å lese:

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

For et mer nyttig estimat per prosess for din nåværende bruker, bruk:

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

Behandle dette resultatet som et diagnostisk estimat snarere enn perfekt regnskapsføring, spesielt når filbeskrivelser deles. Hensikten er å avdekke åpenbare syndere som flere gamle utviklingsservere, dupliserte IDE-instanser eller flere overvåkere over det samme store depotet.

Trinn 4: Stopp foreldede overvåkere og prøv på nytt før du øker grensen

Hvis du finner utviklingsservere eller verktøy du ikke lenger trenger, må du først lukke dem på vanlig måte. Å starte en editor eller utviklerserver med mye overvåking på nytt kan også frigjøre overvåkinger som er etterlatt av en langvarig økt. Unngå en bred killallkommando med mindre du forstår nøyaktig hva den vil stoppe.

Etter at du har lukket de mistenkte prosessene, kjør den opprinnelige kommandoen på nytt. Hvis den nå fungerer, trenger du kanskje ikke en kjerneendring i det hele tatt. Gjentatt utmattelse tyder imidlertid på at arbeidsmengden reelt sett trenger flere overvåkinger, eller at verktøyet overvåker for mye.

Trinn 5: Test en høyere max_user_watches-verdi midlertidig

En runtime sysctl-endring er nyttig fordi du kan teste den før du gjør den permanent. Registrer først gjeldende verdi:

sysctl fs.inotify.max_user_watches

Velg deretter en verdi som er stor nok for den observerte arbeidsmengden. Hvis du for eksempel bevisst bestemmer deg for å teste 524 288 klokker:

sudo sysctl fs.inotify.max_user_watches=524288

Dette er en eksempelverdi, ikke en universell anbefaling . Inotify-grensene finnes for bundet kjerneressursforbruk, så det er ikke gratis å øke dem uten å forstå arbeidsmengden. En bedre tilnærming er å øke antallet målte trinn, prøve programmet på nytt og stoppe når du har rimelig kapasitet.

sysctl (8)-manualen dokumenterer lesing og endring av kjerneparametere under kjøring.

Trinn 6: Gjør den testede verdien permanent

Hvis den midlertidige endringen løser problemet og verdien er passende for maskinen din, lagrer du den i en sysctl-konfigurasjonsfil. På systemd-baserte distribusjoner kan en lokal administrator plassere konfigurasjonen i /etc/sysctl.d/*.conf. Systemd sysctl.d-dokumentasjonen forklarer at filer i /etc/sysctl.d/er ment for lokal administratorkonfigurasjon og behandles i filnavnrekkefølge.

Opprett en dedikert fil i stedet for å grave ned endringen blant urelaterte innstillinger:

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

Legg til verdien du allerede har testet:

fs.inotify.max_user_watches=524288

Hvis systemet ditt ikke bruker systemds sysctl.d-flyt, bør du se i distribusjonens dokumentasjon før du velger en permanent konfigurasjonsplassering.

Trinn 7: Bruk den vedvarende konfigurasjonen og bekreft den

Du kan starte datamaskinen på nytt, men det er vanligvis unødvendig. På systemer med procps- sysctlverktøyet, bruk systemkonfigurasjonen med:

sudo sysctl --system

Bekreft deretter den aktive verdien:

sysctl fs.inotify.max_user_watches

Den aktive verdien skal samsvare med den tiltenkte innstillingen. Hvis den ikke gjør det, sjekk utdataene sysctl --systemfor en senere konfigurasjonsfil som overstyrer oppføringen din. Navnereglene for sysctl.d er viktige fordi senere filnavn kan prioriteres når den samme variabelen tilordnes mer enn én gang.

Trinn 8: Start applikasjonen på nytt og reduser unødvendig overvåkningsomfang

Start programmet som opprinnelig feilet. Hvis det starter normalt, fungerer kjernesideløsningen. Ikke stopp der hvis overvåkingsbruken forblir uventet høy. Konfigurer programmet, der det støttes, til å ekskludere kataloger som ikke trenger live-overvåking, for eksempel generert byggeutdata, hurtigbuffere, store logger, leverandørtrær eller avhengighetskataloger.

Å redusere overvåkingsområdet er ofte den beste langsiktige løsningen fordi det reduserer kjerneressursbruken og reduserer behandling av filhendelser. Noen verktøy tilbyr polling som en reserve, men polling kan øke CPU- og I/O-aktivitet, så det er vanligvis bedre å behandle det som et kompatibilitetsalternativ snarere enn den første løsningen.

Hva om feilen fortsatt vises?

Sjekk om max_user_instances er den virkelige begrensningen

max_user_instancesbegrenser antall inotify-forekomster per reell bruker-ID. Feilmodusen er imidlertid annerledes: den nåværende inotify_init(2)-manualen dokumenterer EMFILEnår grensen for inotify-forekomst per bruker er nådd. Det betyr at den nøyaktige ENOSPC-overvåkingsmeldingen peker mer direkte på overvåkinger eller ressursallokering, ikke automatisk på forekomstgrensen.

Ikke grip etter ulimit -n først

ulimit -nstyrer prosessens grense for åpne filer. Filbeskrivelser er relatert til inotify-instanser, men én inotify-instans kan inneholde mange overvåkninger. Å øke grensen for åpne filer er derfor ikke den direkte løsningen for en inotify_add_watch()ENOSPC forårsaket av max_user_watches.

Containere kan kanskje ikke endre denne sysctl-en.

Docker dokumenterer at ikke alle sysctl-er har navneområde, og at de ikke støtter endring av container-sysctl-er som ville endre vertssystemet. Hvis den feilende arbeidsmengden kjører i Docker og fs.inotify.max_user_watcheskontrolleres av vertskjernen, må du gjøre endringen på riktig vert eller virtuell maskin i stedet for å tvinge den frem fra en ikke-privilegert container. Se Dockers runtime sysctl-dokumentasjon .

Vanlige feil å unngå

• Forutsatt at ENOSPC alltid betyr en full disk. Systemkallet inotify bruker eksplisitt ENOSPC for overvåkingsgrense-/ressursfeil.
• Endre max_queued_events i stedet for max_user_watches. Køgrensen styrer ventende hendelser, ikke hvor mange filsystemobjekter en bruker kan se.
• Setter en enorm verdi uten å måle. Inotify-grenser finnes for å begrense kjerneressursbruken; øk den bevisst.
• Gjør en permanent endring før du tester den. En midlertidig sysctlendring er enklere å validere og rulle tilbake.
• Glemmer dupliserte overvåkingsprosesser. Flere redigeringsprogrammer, utviklingsservere eller synkroniseringsverktøy kan bruke den samme poolen per bruker.
• Bruker sudo echo value > /proc/...og forventer at sudo skal dekke omdirigeringen. Skallet utfører >kjøringer sudo. Bruk sudo sysctl ...i stedet.

Rask diagnostisk sjekkliste

Primær dokumentasjon

Oppførselen som beskrives her kommer fra dokumentasjonen for brukergrensesnittet i Linux-kjernen, dokumentasjonen for proc-filsystemet, systemds sysctl.d-dokumentasjon og Dockers runtime-dokumentasjon. For de viktigste detaljene, se inotify(7) , inotify_add_watch(2) , proc_pid_fdinfo(5) og sysctl.d(5) .