Sådan rettes "ENOSPC: Systemgrænse for filovervågning nået" i Linux

Hvis et Linux-udviklingsværktøj pludselig stopper med ENOSPC: System limit for number of file watchers reached, kan beskeden være misvisende. ENOSPClyder normalt som "ingen plads tilbage på enheden", men i denne specifikke sti betyder det ofte ikke , at din disk er fuld. Linux- inotify_add_watch()manualen siger, ENOSPCat kan returneres, når grænsen pr. bruger for inotify-overvågning er nået, eller når kernen ikke kan allokere en nødvendig ressource. Denne sondring er vigtig, fordi sletning af filer muligvis ikke gør noget for at løse problemet.

Denne guide gennemgår først diagnosen, derefter den mindst forstyrrende løsning og til sidst en vedvarende konfiguration. Kommandoerne gælder for Linux-systemer, der bruger kernens inotify- grænseflade, som lader applikationer overvåge filer og mapper for ændringer. Udviklingsservere, IDE'er, synkroniseringsklienter, testkørere og byggeværktøjer er ofte afhængige af den.

Dokumentationen til Linux man-pages blev kontrolleret den 13. september 2026. De vigtigste referencer er den aktuelle inotify_add_watch(2) manual og inotify(7) oversigt .

Hvad du har brug for, før du ændrer noget

Du skal bruge en terminal, og for at ændre kerneparametre, en konto, der kan bruge sudo. Gem ikke-gemt arbejde, før du stopper udviklingsservere eller editorer. Bemærk også, hvor den fejlende kommando kører: direkte på Linux, i en virtuel maskine, i WSL eller inde i en container. En container kan dele kerneindstillinger med sin vært og har muligvis ikke tilladelse til at ændre en sysctl på værtsniveau.

Start ikke med at kopiere en meget stor overvågningsgrænse fra et forumindlæg. Tjek først din nuværende indstilling, og identificer, om forældede eller duplikerede overvågningsprocesser bruger den.

Trin 1: Bekræft, at dette er inotify watcher-fejlen

Kør den kommando, der mislykkedes, og læs hele fejlen. Typiske udløsere inkluderer start af en JavaScript-udviklingsserver, en testkørsel til filovervågning eller et IDE-arbejdsområde, der indeholder et meget stort mappetræ. Den vigtige sætning er "systemgrænsen for antallet af filovervågningsprogrammer nået".

Hvis fejlen i stedet opstår ENOSPCunder skrivning af en fil, skal du kontrollere diskkapacitet og inode-tilgængelighed med kommandoer som f.eks. df -hog df -i. Denne artikel handler specifikt om inotify watcher-limit-formen af ​​ENOSPC.

Trin 2: Læs de nuværende inotify-grænser

Linux eksponerer inotify-begrænsninger under /proc/sys/fs/inotify/. En watch er et overvåget filsystemobjekt i en inotify-instans. Kerneldokumentationen skelner mellem tre kontroller:

• max_user_watches: maksimalt antal overvågninger for ét rigtigt bruger-ID.
• max_user_instances: maksimalt antal inotify-instanser for ét rigtigt bruger-ID.
• max_queued_events: maksimalt antal hændelser i kø for en inotify-instans.

Tjek dem uden at ændre noget:

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

Du kan også aflæse den første værdi direkte:

cat /proc/sys/fs/inotify/max_user_watches

Må ikke forveksles fs.inotify.max_user_watchesmed fs.epoll.max_user_watches. De er forskellige kernemekanismer. For denne fejl er du normalt interesseret i inotify-stien.

Trin 3: Led efter processer, der bruger mange overvågninger

Kernen eksponerer inotify-overvågningsoplysninger i hver process /proc/<pid>/fdinfoposter. Dokumentationen proc_pid_fdinfo(5) angiver, at linjer, der starter med , inotifybeskriver overvågede filer eller mapper.

For en hurtig inspektion viser denne kommando inotify-linjer, som dine tilladelser tillader dig at læse:

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

For et mere brugbart estimat pr. proces for din nuværende bruger, brug:

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

Behandl outputtet som et diagnostisk estimat snarere end en perfekt beregning, især når filbeskrivelser deles. Formålet er at afsløre åbenlyse syndere såsom flere gamle udviklingsservere, duplikerede IDE-instanser eller flere watchere over det samme store repository.

Trin 4: Stop forældede watchers og prøv igen, før du hæver grænsen

Hvis du finder udviklingsservere eller -værktøjer, du ikke længere har brug for, skal du først lukke dem normalt. Genstart af en editor eller udviklerserver med mange overvågere kan også frigive overvågninger efter en langvarig session. Undgå en bred killallkommando, medmindre du forstår præcis, hvad den vil stoppe.

Efter at have lukket de mistænkte processer, skal du køre din oprindelige kommando igen. Hvis den nu virker, behøver du muligvis slet ikke en kerneændring. Gentagen udmattelse tyder dog på, at arbejdsbyrden reelt har brug for flere overvågninger, eller at værktøjet overvåger for meget.

Trin 5: Test midlertidigt en højere max_user_watches-værdi

En runtime sysctl-ændring er nyttig, fordi du kan teste den, før du gør den persistent. Registrer først den aktuelle værdi:

sysctl fs.inotify.max_user_watches

Vælg derefter en værdi, der er stor nok til den observerede arbejdsbyrde. Hvis du for eksempel bevidst beslutter dig for at teste 524.288 ure:

sudo sysctl fs.inotify.max_user_watches=524288

Dette er en eksempelværdi, ikke en universel anbefaling . Inotify-grænserne findes for bundet kerne-ressourceforbrug, så det er ikke gratis at hæve dem uden at forstå arbejdsbyrden. En bedre tilgang er at øge antallet af målte trin, prøve programmet igen og stoppe, når du har rimelig plads.

sysctl (8)-manualen dokumenterer læsning og ændring af kerneparametre under kørsel.

Trin 6: Gør den testede værdi persistent

Hvis den midlertidige ændring løser problemet, og værdien er passende for din maskine, skal du gemme den i en sysctl-konfigurationsfil. På systemd-baserede distributioner kan en lokal administrator placere konfigurationen i /etc/sysctl.d/*.conf. Systemd sysctl.d-dokumentationen forklarer, at filer i /etc/sysctl.d/er beregnet til lokal administratorkonfiguration og behandles i filnavnrækkefølge.

Opret en dedikeret fil i stedet for at gemme ændringen blandt uafhængige indstillinger:

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

Tilføj den værdi, du allerede har testet:

fs.inotify.max_user_watches=524288

Hvis dit system ikke bruger systemds sysctl.d-flow, skal du konsultere din distributions dokumentation, før du vælger en permanent konfigurationsplacering.

Trin 7: Anvend den permanente konfiguration, og bekræft den

Du kan genstarte, men det er normalt unødvendigt. På systemer med procps- sysctlværktøjet skal du anvende systemkonfigurationen med:

sudo sysctl --system

Bekræft derefter den aktive værdi:

sysctl fs.inotify.max_user_watches

Den aktive værdi skal stemme overens med din tilsigtede indstilling. Hvis den ikke gør det, skal du kontrollere outputtet sysctl --systemfor en senere konfigurationsfil, der tilsidesætter din indtastning. Navngivningsreglerne for sysctl.d er vigtige, fordi senere filnavne kan have forrang, når den samme variabel tildeles mere end én gang.

Trin 8: Genstart applikationen og reducer unødvendigt overvågningsområde

Start den applikation, der oprindeligt fejlede. Hvis den starter normalt, virker kernesideløsningen. Stop ikke der, hvis overvågningsforbruget forbliver uventet højt. Konfigurer applikationen, hvor det understøttes, til at ekskludere mapper, der ikke kræver liveovervågning, såsom genereret build-output, cacher, store logfiler, leverandørtræer eller afhængighedsmapper.

At reducere overvågningsomfanget er ofte den bedste langsigtede løsning, fordi det sænker brugen af ​​kerneressourcer og reducerer filhændelsesbehandling. Nogle værktøjer tilbyder polling som en fallback, men polling kan øge CPU- og I/O-aktivitet, så det er normalt bedre at behandle det som en kompatibilitetsmulighed end den første løsning.

Hvad hvis fejlen stadig vises?

Tjek om max_user_instances er den reelle begrænsning

max_user_instancesbegrænser antallet af inotify-instanser pr. reelt bruger-ID. Fejltilstanden er dog anderledes: den nuværende inotify_init(2)-manual dokumenterer, EMFILEhvornår grænsen for inotify-instanser pr. bruger er nået. Det betyder, at den nøjagtige ENOSPC-overvågningsmeddelelse mere direkte peger på overvågninger eller ressourceallokering, ikke automatisk på instansgrænsen.

Ræk ikke ud efter ulimit -n først

ulimit -nstyrer processens grænse for åbne filbeskrivelser. Filbeskrivelser er relateret til inotify-instanser, men én inotify-instans kan indeholde mange overvågninger. At hæve grænsen for åbne filer er derfor ikke den direkte løsning på en inotify_add_watch()ENOSPC forårsaget af max_user_watches.

Containere kan muligvis ikke ændre denne sysctl

Docker dokumenterer, at ikke alle sysctl'er har navnespace, og at de ikke understøtter ændring af container-sysctl'er, der ville ændre værtssystemet. Hvis den fejlende arbejdsbelastning kører i Docker og fs.inotify.max_user_watchesstyres af værtskernen, skal du foretage ændringen på den relevante vært eller VM i stedet for at tvinge den fra en ikke-privilegeret container. Se Dockers runtime sysctl-dokumentation .

Almindelige fejl at undgå

• Hvis vi antager, at ENOSPC altid betyder en fuld disk, bruger inotify-systemkaldet eksplicit ENOSPC til watch-limit/ressourcefejl.
• Ændring af max_queued_events i stedet for max_user_watches. Køgrænsen styrer ventende hændelser, ikke hvor mange filsystemobjekter en bruger må overvåge.
• Sætter en enorm værdi uden at måle. Inotify har grænser for at begrænse kerneressourceforbruget; øg det bevidst.
• Foretager en permanent ændring, før den testes. En midlertidig sysctlændring er nemmere at validere og rulle tilbage.
• Glemmer dubletter af watcherprocesser. Flere editorer, udviklingsservere eller synkroniseringsværktøjer kan bruge den samme pulje pr. bruger.
• Bruger sudo echo value > /proc/...og forventer at sudo dækker omdirigeringen. Shell'en udfører kørsel >før sudokørsel. Brug sudo sysctl ...i stedet.

Hurtig diagnostisk tjekliste

Primær dokumentation

Den adfærd, der beskrives her, stammer fra dokumentationen til Linux-kernens brugergrænseflade, dokumentationen til proc-filsystemet, systemds sysctl.d-dokumentation og Dockers runtime-dokumentation. For de vigtigste detaljer, se inotify(7) , inotify_add_watch(2) , proc_pid_fdinfo(5) og sysctl.d(5) .