Eroarea „too many open files” apare atunci când un proces atinge limita de descriptori de fișiere pe care îi poate deschide. În Linux, „fișier” nu înseamnă doar documente de pe disc. Aici intră și socket-uri de rețea, pipe-uri, fișiere de log, dispozitive și alte resurse urmărite prin file descriptors. Din acest motiv, un server web, un proxy, o bază de date sau chiar un serviciu de monitorizare poate ajunge la limită fără să aibă mii de fișiere clasice deschise.
Primul lucru important este să separi problema pe niveluri. La nivel de proces, limita este controlată de RLIMIT_NOFILE, adică numărul maxim de descriptori pe care procesul îi poate avea deschiși. Dacă această limită este depășită, apelurile obișnuite precum open, pipe sau dup pot eșua, iar aplicația va raporta de regulă „Too many open files” sau EMFILE. La nivel de serviciu, dacă procesul pornește prin systemd, limita poate fi influențată de LimitNOFILE=. La nivel de sistem, kernelul mai are și limite globale relevante, în special fs.file-max și plafonul fs.nr_open.
Pentru diagnostic, începe cu procesul afectat. Dacă aplicația rulează deja, verifică limitele reale ale procesului, nu doar ce crezi că ai configurat. O metodă sigură este:
cat /proc/PID/limits
În ieșire te interesează linia „Max open files”. Dacă vrei un rezumat rapid, poți folosi și:
prlimit –pid PID –nofile
Dacă procesul a fost pornit din shell-ul curent, merită verificat și:
ulimit -n
Atenție însă: ulimit arată limita sesiunii curente, nu neapărat limita unui serviciu systemd deja pornit.
Ca să vezi dacă problema este consum real sau doar o limită prea mică, verifică și câți descriptori are procesul deschiși:
ls /proc/PID/fd | wc -l
Dacă numărul urcă constant și nu coboară, ai posibil un file descriptor leak. În acest caz, creșterea limitei poate masca temporar problema, dar nu o rezolvă.
Dacă aplicația rulează ca serviciu systemd, verifică direct proprietatea expusă de managerul de servicii:
systemctl show NUME_SERVICIU -p LimitNOFILE
Dacă serviciul are un override local, îl poți inspecta cu:
systemctl cat NUME_SERVICIU
Aici cauți dacă există LimitNOFILE= în unitatea principală sau într-un drop-in. Documentația systemd arată și un detaliu important: ridicarea soft limit peste 1024 poate crea probleme aplicațiilor vechi care folosesc select(2), deoarece select nu poate lucra cu descriptori peste 1023. Cu alte cuvinte, nu ridici orbește limita doar pentru că pare soluția rapidă.
Pentru servicii systemd, remedierea persistentă se face în unitate sau într-un override, de exemplu prin:
systemctl edit NUME_SERVICIU
Apoi adaugi în secțiunea [Service]:
LimitNOFILE=65535
După modificare:
systemctl daemon-reload
systemctl restart NUME_SERVICIU
Dacă limita nu este setată explicit pe serviciu, se poate aplica valoarea implicită a managerului systemd. Documentația systemd indică pentru DefaultLimitNOFILE= un implicit istoric de 1024:524288, adică soft 1024 și hard 524288, dar valoarea efectivă poate depinde de distribuție și de configurarea locală. Verificarea practică rămâne esențială.
Pentru sesiuni de utilizator pornite prin PAM, limitele persistente se configurează de regulă în /etc/security/limits.conf sau în fișiere din /etc/security/limits.d/. Aici intrările nofile definesc limite soft și hard pentru utilizatori sau grupuri. Este util pentru procese pornite din login shell sau sesiuni interactive, dar nu trebuie confundat automat cu serviciile systemd de sistem. După modificare, de obicei este necesară o sesiune nouă.
Dacă ai confirmat că limita per proces este deja suficient de mare, următorul pas este kernelul. Documentația kernel explică faptul că fs.file-max reprezintă numărul maxim de file handles pe care kernelul le alocă global. Când această limită este atinsă, în logurile de kernel poate apărea mesajul:
VFS: file-max limit reached
Verifici valorile astfel:
sysctl fs.file-max
sysctl fs.nr_open
fs.nr_open este plafonul superior pentru câte file handles poate avea un singur proces. Dacă încerci să ridici hard limit peste acest prag, operația poate fi refuzată. Persistența pentru aceste valori se face de regulă prin fișiere din /etc/sysctl.d/, apoi:
sysctl –system
Regula practică este simplă: întâi identifici unde se blochează exact, apoi mărești doar nivelul necesar. Dacă sari direct la kernel sau pui limite foarte mari peste tot, riști să ascunzi un bug de aplicație, un leak de socket-uri sau o rotație defectuoasă a logurilor. O depanare bună înseamnă verificare pe proces, confirmare în systemd și intervenție în kernel doar când datele chiar o cer.
