Kuinka korjata "ENOSPC: Järjestelmän raja tiedostojen tarkkailijoille saavutettu" Linuxissa

Jos Linux-kehitystyökalu pysähtyy yhtäkkiä ja näyttää virheen ENOSPC: System limit for number of file watchers reached, viesti voi olla harhaanjohtava. ENOSPCYleensä se näyttää "laitteella ei ole tilaa jäljellä", mutta tässä tietyssä polussa se ei usein tarkoita, että levy on täynnä. Linuxin inotify_add_watch()käyttöohjeen mukaan ENOSPCse voidaan palauttaa, kun inotify-katselujen käyttäjäkohtainen raja on saavutettu tai kun ydin ei pysty varaamaan tarvittavaa resurssia. Tällä erolla on merkitystä, koska tiedostojen poistaminen ei välttämättä ratkaise ongelmaa mitenkään.

Tämä opas käy ensin läpi vianmäärityksen, sitten vähiten häiritsevän korjauksen ja lopuksi pysyvän kokoonpanon. Komennot koskevat Linux-järjestelmiä, jotka käyttävät ytimen inotify- käyttöliittymää, jonka avulla sovellukset voivat valvoa tiedostojen ja hakemistojen muutoksia. Kehityspalvelimet, IDE:t, synkronointiasiakkaat, testiajoohjelmat ja käännöstyökalut ovat usein riippuvaisia ​​siitä.

Linuxin man-sivujen dokumentaatio tarkastettiin 13. syyskuuta 2026. Tärkeimmät viitteet ovat nykyinen inotify_add_watch(2)-manuaali ja inotify(7)-yleiskatsaus .

Mitä tarvitset ennen kuin muutat mitään

Tarvitset pääteohjelman ja ytimen parametrien muuttamista varten tilin, joka voi käyttää sudo. Tallenna tallentamaton työ ennen kehityspalvelimien tai editorien pysäyttämistä. Huomaa myös, missä epäonnistunut komento suoritetaan: suoraan Linuxissa, virtuaalikoneessa, WSL:ssä vai säilön sisällä. Säiliö saattaa jakaa ytimen asetuksia isäntänsä kanssa, eikä sillä välttämättä ole oikeutta muuttaa isäntätason sysctl-komentoa.

Älä aloita kopioimalla erittäin suurta tarkkailijarajoitusta foorumiviestistä. Tarkista ensin nykyinen asetuksesi ja selvitä, käyttävätkö vanhentuneet tai kahdentuneet tarkkailijaprosessit sitä.

Vaihe 1: Vahvista, että tämä on inotify-valvontavirhe

Suorita epäonnistunut komento ja lue koko virhe. Tyypillisiä laukaisimia ovat JavaScript-kehityspalvelimen käynnistys, tiedostojen tarkkailua suorittava testiohjelma tai IDE-työtila, joka sisältää erittäin suuren hakemistopuun. Tärkeä lause on "tiedostojen tarkkailijoiden määrän järjestelmäraja saavutettu".

Jos virhe ilmenee ENOSPCtiedoston kirjoittamisen aikana, tarkista levyn kapasiteetti ja inode-komennon saatavuus komennoilla, kuten df -hja df -i. Tämä artikkeli käsittelee erityisesti ENOSPC:n inotify watcher-limit -muotoa.

Vaihe 2: Lue nykyiset inotify-rajoitukset

Linux paljastaa inotify-rajoitukset kohdassa /proc/sys/fs/inotify/. Watch on yksi valvottu tiedostojärjestelmäobjekti inotify-instanssin sisällä. Ytimen dokumentaatiossa erotetaan toisistaan ​​kolme ohjausobjektia:

• max_user_watches: yhden oikean käyttäjätunnuksen katselukertojen enimmäismäärä.
• max_user_instances: inotify-instanssien enimmäismäärä yhtä oikeaa käyttäjätunnusta kohden.
• max_queued_events: inotify-instanssin jonossa olevien tapahtumien enimmäismäärä.

Tarkista ne muuttamatta mitään:

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

Voit myös lukea ensimmäisen arvon suoraan:

cat /proc/sys/fs/inotify/max_user_watches

Älä sekoita fs.inotify.max_user_watches. fs.epoll.max_user_watchesNe ovat eri ytimen mekanismeja. Tässä virheessä välität yleensä inotify-polusta.

Vaihe 3: Etsi prosesseja, jotka kuluttavat useita seurantajaksoja

Ydin näyttää inotify-valvontatiedot jokaisen prosessin /proc/<pid>/fdinfomerkinnöissä. Proc_pid_fdinfo(5):n dokumentaatiossa todetaan, että merkkijonoilla alkavat rivit inotifykuvaavat valvottuja tiedostoja tai hakemistoja.

Nopeaa tarkistusta varten tämä komento näyttää inotify-rivit, jotka käyttöoikeutesi sallivat sinun lukea:

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

Saat hyödyllisemmän prosessikohtaisen arvion nykyiselle käyttäjällesi käyttämällä:

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

Käsittele tätä tulostetta diagnostisena arviona täydellisen kirjanpidon sijaan, varsinkin kun tiedostokuvauksia jaetaan. Sen tarkoituksena on paljastaa ilmeisiä rikollisia, kuten useita vanhoja kehityspalvelimia, kaksoiskappaleita IDE-instansseja tai useita tarkkailijoita samassa suuressa arkistossa.

Vaihe 4: Pysäytä vanhentuneet tarkkailijat ja yritä uudelleen ennen rajan nostamista

Jos löydät kehityspalvelimia tai -työkaluja, joita et enää tarvitse, sulje ne ensin normaalisti. Myös paljon tarkkailuohjelmia käyttävän editorin tai kehityspalvelimen uudelleenkäynnistäminen voi vapauttaa pitkään jatkuneen istunnon jättämiä tarkkailuja. Vältä laajaa killallkomentoa, ellet ymmärrä tarkalleen, mitä se pysäyttää.

Sulje epäillyt prosessit ja suorita alkuperäinen komento uudelleen. Jos se nyt toimii, et ehkä tarvitse ytimen vaihtoa ollenkaan. Toistuva ylikuormitus kuitenkin viittaa siihen, että työmäärä todella tarvitsee lisää tarkkailuja tai että työkalu tarkkailee liikaa.

Vaihe 5: Testaa korkeampaa max_user_watches-arvoa väliaikaisesti

Ajonaikainen sysctl-muutos on hyödyllinen, koska voit testata sen ennen kuin teet siitä pysyvän. Kirjaa ensin nykyinen arvo:

sysctl fs.inotify.max_user_watches

Valitse sitten arvo, joka on riittävän suuri havaitulle työmäärälle. Jos esimerkiksi päätät testata 524 288 kelloa:

sudo sysctl fs.inotify.max_user_watches=524288

Tämä on esimerkkiarvo, ei yleismaailmallinen suositus . Inotify-rajoitukset koskevat sidottua ytimen resurssien kulutusta, joten niiden nostaminen ilman työmäärän ymmärtämistä ei ole ilmaista. Parempi lähestymistapa on lisätä arvoa mitatuissa vaiheissa, yrittää sovellusta uudelleen ja lopettaa, kun sinulla on riittävästi resursseja.

sysctl (8)-käyttöohjeessa käsitellään ytimen parametrien lukemista ja muuttamista ajonaikana.

Vaihe 6: Tee testatusta arvosta pysyvä

Jos väliaikainen muutos korjaa ongelman ja arvo sopii koneellesi, tallenna se sysctl-määritystiedostoon. Systemd-pohjaisissa jakeluissa paikallinen järjestelmänvalvoja voi tallentaa määritykset kansioon /etc/sysctl.d/*.conf. systemd:n ​​sysctl.d-tiedoston dokumentaatiossa selitetään, että tiedostot kannassa /etc/sysctl.d/on tarkoitettu paikallisen järjestelmänvalvojan määrityksiin ja ne käsitellään tiedostonimijärjestyksessä.

Luo erillinen tiedosto sen sijaan, että hautaisit muutoksen toisiinsa liittymättömien asetusten joukkoon:

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

Lisää jo testaamasi arvo:

fs.inotify.max_user_watches=524288

Jos järjestelmäsi ei käytä systemd:n ​​sysctl.d-työnkulkua, tutustu jakelusi dokumentaatioon ennen pysyvän määrityssijainnin valitsemista.

Vaihe 7: Käytä pysyvää kokoonpanoa ja tarkista se

Voit käynnistää järjestelmän uudelleen, mutta se on yleensä tarpeetonta. Järjestelmissä, joissa on procps- sysctltyökalu, määritä järjestelmän asetukset seuraavasti:

sudo sysctl --system

Tarkista sitten aktiivinen arvo:

sysctl fs.inotify.max_user_watches

Aktiivisen arvon tulisi vastata haluamaasi asetusta. Jos se ei vastaa, tarkista funktion tulosteesta sysctl --systemmyöhempi määritystiedosto, joka korvaa syötteesi. sysctl.d-tiedoston nimeämissäännöt ovat tärkeitä, koska myöhemmät tiedostonimet voivat olla etusijalla, kun sama muuttuja määritetään useammin kuin kerran.

Vaihe 8: Käynnistä sovellus uudelleen ja vähennä tarpeetonta tarkkailun laajuutta

Käynnistä sovellus, joka alun perin epäonnistui. Jos se käynnistyy normaalisti, kernel-puolen korjaus toimii. Älä pysähdy tähän, jos valvontatoimintojen käyttö pysyy odottamattoman korkeana. Määritä sovellus, jos se on tuettu, jättämään pois hakemistot, jotka eivät tarvitse reaaliaikaista valvontaa, kuten luodut koontitulosteet, välimuistit, suuret lokit, toimittajapuut tai riippuvuushakemistot.

Tarkkailualueen pienentäminen on usein paras pitkän aikavälin ratkaisu, koska se vähentää ytimen resurssien käyttöä ja tiedostotapahtumien käsittelyä. Jotkin työkalut tarjoavat kyselyn vararatkaisuna, mutta kysely voi lisätä suorittimen ja I/O:n aktiivisuutta, joten sitä on yleensä parempi käsitellä yhteensopivuusvaihtoehtona kuin ensisijaisena ratkaisuna.

Mitä jos virhe näkyy edelleen?

Tarkista, onko max_user_instances todellinen rajoite

max_user_instancesrajoittaa inotify-instanssien määrää todellista käyttäjätunnusta kohden. Virhetila on kuitenkin erilainen: nykyinen inotify_init(2)-manuaali dokumentoi, EMFILEmilloin käyttäjäkohtainen inotify-instanssien raja saavutetaan. Tämä tarkoittaa, että tarkka ENOSPC-tarkkailijaviesti viittaa suoremmin tarkkailuihin tai resurssien allokointiin, ei automaattisesti instanssien rajaan.

Älä käytä komentoa ulimit -n ensin

ulimit -nhallitsee prosessin avoimen tiedoston kuvaajien rajaa. Tiedostokuvaajat liittyvät inotify-instansseihin, mutta yksi inotify-instanssi voi sisältää useita tarkkailuja. Avoimen tiedoston rajan nostaminen ei siis ole suora ratkaisu .:n inotify_add_watch()aiheuttamaan ENOSPC-ongelmaan max_user_watches.

Säiliöt eivät välttämättä pysty muuttamaan tätä sysctl-arvoa.

Docker dokumentoi, että kaikki sysctl-käskyt eivät ole nimiavaruuden mukaisia ​​eikä se tue säilön sysctl-käskyjen muuttamista siten, että se muuttaisi isäntäjärjestelmää. Jos virheellinen työkuorma suoritetaan Dockerissa ja fs.inotify.max_user_watchessitä ohjaa isäntäydin, tee muutos asianmukaisessa isännässä tai virtuaalikoneessa sen sijaan, että pakottaisit sen etuoikeuttamattomasta säilöstä. Katso Dockerin ajonaikaisen sysctl-dokumentaatio .

Yleisiä virheitä, joita kannattaa välttää

• Olettaen, että ENOSPC tarkoittaa aina täyttä levyä. Inotify-järjestelmäkutsu käyttää eksplisiittisesti ENOSPC:tä valvontarajoitusten/resurssien virheiden varalta.
• Muutetaan max_queued_events-arvoa max_user_watches-arvon sijaan. Jonon raja-arvo ohjaa odottavia tapahtumia, ei sitä, kuinka monta tiedostojärjestelmäobjektia käyttäjä voi tarkkailla.
• Valtavan arvon asettaminen mittaamatta. Ytimen resurssien käyttöä rajoittavat Inotify-rajoitukset; nosta niitä tarkoituksella.
• Pysyvän muutoksen tekeminen ennen sen testaamista. Väliaikainen sysctlmuutos on helpompi validoida ja peruuttaa.
• Unohdataan päällekkäiset tarkkailuprosessit. Useat editorit, kehityspalvelimet tai synkronointityökalut voivat käyttää samaa käyttäjäkohtaista poolia.
• Käytetään sudo echo value > /proc/...ja odotetaan sudo-komentoa uudelleenohjauksen kattamiseksi. Komentotulkki suoritetaan >ennen sudosuorituksia. Käytä sudo sysctl ...sen sijaan.

Nopea diagnostiikkatarkistuslista

Ensisijainen dokumentaatio

Tässä kuvattu toimintatapa on peräisin Linux-ytimen käyttäjätilan käyttöliittymän dokumentaatiosta, proc-tiedostojärjestelmän dokumentaatiosta, systemd:n ​​sysctl.d-dokumentaatiosta ja Dockerin ajonaikaisen dokumentaation. Tärkeimmät yksityiskohdat löytyvät inotify(7) , inotify_add_watch(2) , proc_pid_fdinfo(5) ja sysctl.d(5) -tiedostoista .