Ja Linux izstrādes rīks pēkšņi apstājas ar ENOSPC: System limit for number of file watchers reached, ziņojums var būt maldinošs. ENOSPCParasti tas skan kā “ierīcē vairs nav vietas”, taču šajā konkrētajā ceļā tas bieži vien nenozīmē, ka disks ir pilns. Linux inotify_add_watch()rokasgrāmatā teikts, ka ENOSPCto var atgriezt, ja ir sasniegts inotify vērojumu ierobežojums vienam lietotājam vai ja kodols nevar piešķirt nepieciešamo resursu. Šī atšķirība ir svarīga, jo failu dzēšana, iespējams, neko nedarīs, lai atrisinātu problēmu.
Šajā rokasgrāmatā vispirms ir aprakstīta diagnostika, pēc tam vismazāk traucējošais risinājums un visbeidzot pastāvīga konfigurācija. Komandas attiecas uz Linux sistēmām, kas izmanto kodola inotify saskarni, kas ļauj lietojumprogrammām uzraudzīt failu un direktoriju izmaiņas. Izstrādes serveri, IDE, sinhronizācijas klienti, testēšanas programmas un veidošanas rīki bieži vien to izmanto.
Linux rokasgrāmatas lapu dokumentācija tika pārbaudīta 2026. gada 13. septembrī. Galvenās atsauces ir pašreizējā inotify_add_watch(2) rokasgrāmata un inotify(7) pārskats .
Jums ir nepieciešams terminālis un, lai mainītu kodola parametrus, konts, kas var izmantot sudo. Pirms izstrādes serveru vai redaktoru apturēšanas saglabājiet nesaglabāto darbu. Ņemiet vērā arī to, kur darbojas kļūdainā komanda: tieši Linux sistēmā, virtuālajā mašīnā, WSL vai konteinera iekšpusē. Konteiners var koplietot kodola iestatījumus ar savu resursdatoru un, iespējams, nedrīkst mainīt resursdatora līmeņa sysctl.
Nesāciet, kopējot ļoti lielu vērotāju ierobežojumu no foruma ieraksta. Vispirms pārbaudiet pašreizējo iestatījumu un nosakiet, vai to nepatērē novecojuši vai dublēti vērotāju procesi.
Palaidiet komandu, kuras darbība neizdevās, un izlasiet visu kļūdas ziņojumu. Tipiski izraisītāji ir JavaScript izstrādes servera palaišana, failu vērošanas testa skrējējs vai IDE darbvieta, kurā ir ļoti liels direktoriju koks. Svarīgākā frāze ir "sasniegts sistēmas ierobežojums failu vērotāju skaitam".
Ja kļūda rodas ENOSPCfaila ierakstīšanas laikā, pārbaudiet diska ietilpību un inoda pieejamību, izmantojot tādas komandas kā df -hun df -i. Šis raksts ir īpaši par ENOSPC inotify watcher-limit formu.
Linux atklāj inotify ierobežojumus sadaļā /proc/sys/fs/inotify/. Vērotājs ir viens uzraudzīts failu sistēmas objekts inotify instancē. Kodola dokumentācijā ir izšķirtas trīs vadīklas:
max_user_watches: maksimālais vērojumu skaits vienam reālam lietotāja ID.max_user_instances: maksimālais inotify instanču skaits vienam reālam lietotāja ID.max_queued_events: maksimālais inotify instances rindā esošo notikumu skaits.Pārbaudiet tos, neko nemainot:
sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances
sysctl fs.inotify.max_queued_eventsPirmo vērtību var nolasīt arī tieši:
cat /proc/sys/fs/inotify/max_user_watches
Nejauciet fs.inotify.max_user_watchesar fs.epoll.max_user_watches. Tie ir dažādi kodola mehānismi. Šīs kļūdas gadījumā parasti svarīgs ir inotify ceļš.
Kodols katra procesa /proc/<pid>/fdinfoierakstos atklāj inotify uzraudzības informāciju. Proc_pid_fdinfo(5) dokumentācijā ir norādīts, ka rindas, kas sākas ar , inotifyapraksta uzraudzītos failus vai direktorijus.
Ātrai pārbaudei šī komanda parāda inotify rindas, kuras jūsu atļaujas ļauj jums lasīt:
sudo grep -H '^inotify' /proc/[0-9]*/fdinfo/* 2>/dev/null | head -n 50Lai iegūtu noderīgāku aprēķinu par katru procesu jūsu pašreizējam lietotājam, izmantojiet:
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 | headUztveriet šo izvadi kā diagnostikas novērtējumu, nevis perfektu uzskaiti, it īpaši, ja failu deskriptori tiek koplietoti. Tās mērķis ir atklāt acīmredzamus pārkāpējus, piemēram, vairākus vecus izstrādes serverus, dublētus IDE gadījumus vai vairākus novērotājus vienā un tajā pašā lielajā repozitorijā.
/proc/*/fdinfo/*var atklāt, kuri procesi satur inotify watch deskriptorus. Norādītās PID un inode vērtības ir ilustratīvas.Ja atrodat izstrādes serverus vai rīkus, kas jums vairs nav nepieciešami, vispirms aizveriet tos kā parasti. Redaktora vai izstrādes servera, kurā ir daudz vērotāju, restartēšana var arī atbrīvot vērojumus, ko atstājusi ilgstoša sesija. Izvairieties no plašas killallkomandas, ja vien precīzi nezināt, ko tā apturēs.
Pēc aizdomīgo procesu aizvēršanas atkārtoti palaidiet sākotnējo komandu. Ja tā tagad darbojas, iespējams, kodola izmaiņas nemaz nav nepieciešamas. Tomēr atkārtota noslodze liecina, ka darba slodzei ir nepieciešams vairāk novērošanas reižu vai ka rīks novēro pārāk daudz.
pkillir ilustratīvs; izmantojiet sava faktiskā procesa nosaukumu un, ja iespējams, dodiet priekšroku lietojumprogrammas parastajai izslēgšanai.Izpildes laika sysctl izmaiņas ir noderīgas, jo tās var pārbaudīt, pirms tās padarāt pastāvīgas. Vispirms ierakstiet pašreizējo vērtību:
sysctl fs.inotify.max_user_watchesPēc tam izvēlieties vērtību, kas ir pietiekami liela novērotajai darba slodzei. Piemēram, ja apzināti nolemjat pārbaudīt 524 288 pulksteņus:
sudo sysctl fs.inotify.max_user_watches=524288Šī ir vērtības piemērs, nevis universāls ieteikums . Inotify ierobežojumi pastāv ierobežotam kodola resursu patēriņam, tāpēc to palielināšana, neizprotot darba slodzi, nav bezmaksas. Labāka pieeja ir palielināt mērījumu soļus, atkārtoti mēģināt palaist lietojumprogrammu un apturēt, tiklīdz ir iegūta pietiekama brīva vieta.
sysctl (8) rokasgrāmatā ir aprakstīta kodola parametru lasīšana un mainīšana izpildes laikā.
Ja pagaidu izmaiņas novērš problēmu un vērtība ir piemērota jūsu datoram, saglabājiet to sysctl konfigurācijas failā. Systemd balstītos izplatījumos lokālais administrators var ievietot konfigurāciju /etc/sysctl.d/*.conf. systemd sysctl.d dokumentācijā ir paskaidrots, ka faili /etc/sysctl.d/ir paredzēti lokālā administratora konfigurācijai un tiek apstrādāti failu nosaukumu secībā.
Izveidojiet īpašu failu, nevis aprakiet izmaiņas nesaistītos iestatījumos:
sudo nano /etc/sysctl.d/99-inotify.confPievienojiet vērtību, kuru jau pārbaudījāt:
fs.inotify.max_user_watches=524288
Ja jūsu sistēma neizmanto systemd sysctl.d plūsmu, pirms pastāvīgas konfigurācijas atrašanās vietas izvēles iepazīstieties ar savas izplatīšanas dokumentāciju.
Varat pārstartēt sistēmu, bet tas parasti nav nepieciešams. Sistēmās ar procps sysctlrīku lietojiet sistēmas konfigurāciju, izmantojot:
sudo sysctl --systemPēc tam pārbaudiet aktīvo vērtību:
sysctl fs.inotify.max_user_watchesAktīvajai vērtībai ir jāatbilst jūsu paredzētajam iestatījumam. Ja tā neatbilst, pārbaudiet izvadi, vai nav sysctl --systemjaunāks konfigurācijas fails, kas ignorē jūsu ievadīto vērtību. sysctl.d nosaukumu piešķiršanas noteikumi ir svarīgi, jo jaunākiem failu nosaukumiem var būt prioritāte, ja viens un tas pats mainīgais tiek piešķirts vairāk nekā vienu reizi.
Palaidiet lietojumprogrammu, kuras palaišana sākotnēji neizdevās. Ja tā startējas normāli, kodola puses labojums darbojas. Neapstājieties pie tā, ja vērošanas noslodze joprojām ir negaidīti augsta. Konfigurējiet lietojumprogrammu, ja tas tiek atbalstīts, lai izslēgtu direktorijus, kuriem nav nepieciešama tiešraides uzraudzība, piemēram, ģenerēto būvējuma izvadi, kešatmiņas, lielus žurnālus, piegādātāju kokus vai atkarību direktorijus.
Uzraudzības tvēruma samazināšana bieži vien ir labākais ilgtermiņa risinājums, jo tā samazina kodola resursu izmantošanu un samazina failu notikumu apstrādi. Daži rīki piedāvā aptaujas kā rezerves variantu, taču aptaujas var palielināt centrālā procesora un ievades/izvades aktivitāti, tāpēc parasti to labāk uzskatīt par saderības iespēju, nevis pirmo risinājumu.
max_user_instancesierobežo inotify instanču skaitu uz vienu reālu lietotāja ID. Tomēr kļūmes režīms ir atšķirīgs: pašreizējā inotify_init(2) rokasgrāmatā tiek dokumentēts, EMFILEkad tiek sasniegts inotify instanču ierobežojums vienam lietotājam. Tas nozīmē, ka precīzs ENOSPC vērotāja ziņojums tiešāk norāda uz vērotājiem vai resursu piešķiršanu, nevis automātiski uz instanču ierobežojumu.
ulimit -nkontrolē procesa atvērto failu deskriptoru ierobežojumu. Failu deskriptori ir saistīti ar inotify instancēm, taču viena inotify instance var saturēt daudz vērotāju. Tāpēc atvērto failu ierobežojuma palielināšana nav tiešs ENOSPC risinājums, inotify_add_watch()ko izraisa max_user_watches.
Docker dokumentē, ka ne katrs sysctl ir nosaukumtelpas un ka tas neatbalsta konteinera sysctl maiņu, kas modificētu resursdatora sistēmu. Ja kļūdainā darba slodze darbojas Docker vidē un fs.inotify.max_user_watchesto kontrolē resursdatora kodols, veiciet izmaiņas atbilstošajā resursdatorā vai virtuālajā mašīnā, nevis piespiedu kārtā no neprivileģēta konteinera. Skatiet Docker sysctl izpildlaika dokumentāciju .
sysctlizmaiņas ir vieglāk validēt un atsaukt.sudo echo value > /proc/...Pāradresācijas segšanai tiek izmantots un tiek sagaidīts sudo. Apvalks tiek izpildīts >pirms sudopalaišanas. sudo sysctl ...Tā vietā izmantojiet.| Jautājums | Komanda vai darbība | Ko tas jums stāsta |
|---|---|---|
| Vai šī ir ENOSPC vērotāja forma? | Izlasiet pilnu pieteikuma kļūdu | Atdala vērotāja izsīkumu no diska vietas ENOSPC |
| Kāds ir mans vērotāju limits? | sysctl fs.inotify.max_user_watches | Parāda aktīvo skatīšanās reižu skaitu uz vienu lietotāju |
| Kuri procesi izmanto inotify? | Pārbaudīt/proc/<pid>/fdinfo | Palīdz atrast novecojušus vai procesus, kuros ir daudz vērotāju |
| Vai es varu to atrisināt, nemainot kodolu? | Aizveriet dublētus/novecojušus vērotājus un mēģiniet vēlreiz | Izlaiž esošos pulksteņus |
| Vai augstāka robeža to atrisina? | sudo sysctl fs.inotify.max_user_watches=VALUE | Nekavējoties pārbauda izpildlaika vērtību |
| Vai labojums izturēs pārstartēšanu? | Izmantojiet /etc/sysctl.d/*.confun pārbaudiet | Padara pārbaudītu iestatījumu pastāvīgu |
Šeit aprakstītā darbība ir ņemta no Linux kodola lietotāja telpas saskarnes dokumentācijas, proc failu sistēmas dokumentācijas, systemd sysctl.d dokumentācijas un Docker izpildlaika dokumentācijas. Svarīgāko informāciju skatiet inotify(7) , inotify_add_watch(2) , proc_pid_fdinfo(5) un sysctl.d(5) .
Novērsiet Linux ENOSPC failu vērotāja kļūdas, pārbaudot inotify ierobežojumus, atrodot procesus, kuros ir daudz vērotāja resursu, droši paaugstinot ierobežojumus un padarot izmaiņas pastāvīgas.
Novērsiet Tailwind CSS stilu neatjaunināšanu pakalpojumā Vite React, pārbaudot Tailwind v4 iestatījumus, CSS importēšanu, avota noteikšanu, dinamiskās klases, HMR un novecojušas kešatmiņas.
Novērsiet Python 3 ModuleNotFoundError kļūdu pip funkcijai operētājsistēmās Windows, macOS un Linux, izmantojot ensurepip, OS pakotnes, virtuālās vides un interpretētāja pārbaudes.
Novērsiet GitHub SSH atļaujas liegšanu (publiskā atslēga), pārbaudot resursdatoru, aktīvo SSH atslēgu, GitHub kontu, SSO autorizāciju, attālo URL un 22. porta piekļuvi.
Droši izlabojiet Git ne-ātrās pārtīšanas kļūdu. Aizsargājiet lokālo darbu, ielādējiet attālinātus izmaiņu izmaiņu ierakstus, izvēlieties apvienošanu vai atkārtotu bāzi, atrisiniet konfliktus un veiciet izmaiņu pārtīšanu, nezaudējot izmaiņas.
Izlabojiet Nginx 502 Bad Gateway kļūdas ar Node.js augšupējo resursu, pārbaudot lietotnes portu, NGINX žurnālus, proxy_pass adresi, konteineru tīklošanu, taimautus un atkārtotu ielādi.
Novērsta TypeScript kļūda “Tips 'null' nav piešķirams tipam”, izmantojot apvienošanas tipus, sašaurināšanu, noklusējuma vērtības un drošas apgalvojumus, izmantojot strictNullChecks.
Novērsiet Prisma Client ģenerēšanas kļūdu, pārbaudot savu ģeneratoru, shēmu, izvades ceļu, importus, versijas, monorepo iestatījumu un izvietošanas būvēšanas soļus.
Izlabojiet Node.js ERR_MODULE_NOT_FOUND kļūdu ESM, pārbaudot importēšanas ceļus, failu paplašinājumus, pakotņu instalēšanu, eksportēšanu, ESM režīmu un tīrās instalācijas.
Novērsiet Git kļūdu “nevar iegūt vietējo izdevēja sertifikātu”, identificējot uzticības aizmugurprogrammu, instalējot pareizo CA ķēdi un saglabājot SSL verifikāciju iespējotu.
