Zarządzanie zasobami systemowymi za pomocą polecenia `ulimit` w systemie Linux

Polecenie `ulimit` jest wbudowanym narzędziem powłoki w systemach Unix i Linux, które wymusza limity zasobów dla poszczególnych procesów i użytkowników, zapobiegając wyczerpaniu zasobów systemowych przez pojedynczy proces lub użytkownika — takich jak czas CPU, pamięć, otwarte deskryptory plików czy liczba procesów. Działa na poziomie jądra poprzez wywołanie systemowe `setrlimit()`, co czyni je jednym z najbardziej bezpośrednich i niskonakładowych mechanizmów dostępnych administratorom systemów do zarządzania zasobami.

W przypadku każdego serwera obsługującego obciążenia produkcyjne — czy to aplikacji webowej o dużym ruchu, silnika bazy danych, czy stosu mikroserwisów w kontenerach — błędnie skonfigurowane lub nieobecne ustawienia `ulimit` są główną przyczyną kaskadowych awarii, niekontrolowanych procesów i całkowitych przestojów systemu. Właściwe skonfigurowanie tych limitów nie jest opcjonalne — to fundamentalna higiena infrastruktury.

Jak `ulimit` działa pod maską

Gdy proces powłoki wywołuje `ulimit`, uruchamia wywołania systemowe `getrlimit()` i `setrlimit()` zdefiniowane w standardzie POSIX. Każdy limit jest reprezentowany jako para wartości: limit miękki i limit twardy. Są one przechowywane dla każdego procesu w deskryptorze procesu jądra i są dziedziczone przez procesy potomne w czasie `fork()`.

Ten model dziedziczenia jest kluczowy do zrozumienia. Jeśli ustawisz wartości `ulimit` w sesji powłoki, każdy proces uruchomiony z tej powłoki — w tym demony uruchamiane przez skrypty init — dziedziczy te limity. Z kolei limity ustawione w `/etc/security/limits.conf` są stosowane w czasie logowania PAM, a nie w czasie wykonywania, co oznacza, że obowiązują tylko dla nowych sesji logowania, a nie dla już działających usług.

Limity miękkie a limity twarde

Częstym błędem operacyjnym jest ustawianie limitu twardego równego limitowi miękkiemu. Eliminuje to wszelką elastyczność dla procesu w zakresie tymczasowego podnoszenia własnych limitów, co niektóre aplikacje (jak pewne implementacje JVM i silniki baz danych) robią w sposób uzasadniony podczas uruchamiania.

Kompletny przewodnik: flagi zasobów `ulimit`

Praktyczne użycie `ulimit` w kontekście rzeczywistym

Przeglądanie bieżących limitów

“`bash

ulimit -a # All soft limits for the current shell

ulimit -aH # All hard limits for the current shell

“`

Aby sprawdzić limity dla konkretnego działającego procesu (PID), odczytaj bezpośrednio z systemu plików proc — jest to miarodajne źródło, które omija raportowanie na poziomie powłoki:

“`bash

cat /proc/<PID>/limits

“`

Jest to nieocenione przy rozwiązywaniu problemów z usługą uruchomioną przez systemd lub skrypt init, gdzie `ulimit -a` na poziomie powłoki nie odzwierciedla rzeczywistych limitów procesu.

Ustawianie limitów miękkich i twardych

“`bash

Set soft limit for open file descriptors

ulimit -Sn 65536

Set hard limit for open file descriptors

ulimit -Hn 131072

Set both simultaneously (soft = hard = value)

ulimit -n 65536

“`

Wyłączanie zrzutów pamięci w środowisku produkcyjnym

“`bash

ulimit -c 0

“`

Zrzuty pamięci mogą zużyć gigabajty miejsca na dysku w ciągu kilku sekund, gdy proces o dużym zużyciu pamięci ulegnie awarii. Wyłączanie ich w środowisku produkcyjnym jest standardową praktyką, chyba że aktywnie debugujesz. W środowiskach deweloperskich ustaw dedykowaną ścieżkę za pomocą `sysctl kernel.core_pattern` wraz z niezerowym limitem zrzutu pamięci.

Ograniczanie czasu CPU dla niezaufanych procesów

“`bash

ulimit -t 30

“`

Wysyła to `SIGXCPU` do procesu po osiągnięciu miękkiego limitu czasu CPU i `SIGKILL` przy twardym limicie. Jest to szczególnie przydatne w środowiskach hostingu współdzielonego lub przy uruchamianiu skryptów przesłanych przez użytkowników.

Podnoszenie limitu otwartych deskryptorów plików dla usług o wysokiej współbieżności

Nginx, HAProxy, PostgreSQL i Redis wymagają dużej liczby otwartych deskryptorów plików pod obciążeniem. Domyślna wartość systemowa wynosząca 1024 jest niebezpiecznie niska dla środowisk produkcyjnych:

“`bash

ulimit -n 65536

“`

Dotyczy to jednak tylko bieżącej sesji powłoki. W celu trwałej konfiguracji użyj metod opisanych w następnej sekcji.

Utrwalanie ustawień `ulimit`

Metoda 1: `/etc/security/limits.conf`

Jest to standardowe podejście oparte na PAM dla trwałych limitów na poziomie użytkownika:

“`

/etc/security/limits.conf

<domain> <type> <item> <value>

• soft nofile 65536
• hard nofile 131072

nginx soft nproc 4096

nginx hard nproc 8192

postgres soft nofile 65536

postgres hard nofile 65536

postgres soft memlock unlimited

postgres hard memlock unlimited

“`

Symbol wieloznaczny `*` dotyczy wszystkich użytkowników, ale nie dotyczy roota. Root wymaga jawnego wpisu:

“`

root soft nofile 65536

root hard nofile 131072

“`

Upewnij się, że moduł PAM jest załadowany. Sprawdź, czy `/etc/pam.d/common-session` (Debian/Ubuntu) lub `/etc/pam.d/system-auth` (RHEL/CentOS) zawiera:

“`

session required pam_limits.so

“`

Metoda 2: Pliki drop-in `/etc/security/limits.d/`

Dla przejrzystszego zarządzania, szczególnie w systemach zarządzania konfiguracją takich jak Ansible lub Puppet, umieść pliki limitów specyficzne dla usługi w katalogu drop-in:

“`bash

/etc/security/limits.d/99-nginx.conf

nginx soft nofile 65536

nginx hard nofile 131072

“`

Pliki w tym katalogu są przetwarzane po `limits.conf` i nadpisują go, co czyni je idealnymi do dostrajania specyficznego dla aplikacji bez modyfikowania konfiguracji bazowej.

Metoda 3: Jednostki usług systemd (nowoczesny standard)

W przypadku usług zarządzanych przez systemd — co dotyczy większości nowoczesnych dystrybucji Linux — `limits.conf` nie jest stosowany domyślnie. systemd zarządza własnymi limitami zasobów dla każdej jednostki usługi:

“`ini

/etc/systemd/system/nginx.service.d/limits.conf

[Service]

LimitNOFILE=65536

LimitNPROC=4096

LimitCORE=0

LimitMEMLOCK=infinity

“`

Po edycji przeładuj i uruchom ponownie:

“`bash

systemctl daemon-reload

systemctl restart nginx

“`

Zweryfikuj zastosowane limity:

“`bash

cat /proc/$(systemctl show -p MainPID nginx | cut -d= -f2)/limits

“`

Jest to najbardziej niezawodna metoda dla usług produkcyjnych i powinna być domyślnym podejściem na każdym systemie działającym pod kontrolą systemd (Ubuntu 16.04+, CentOS 7+, Debian 8+).

Metoda 4: Pliki profilu powłoki

W przypadku limitów sesji użytkownika stosowanych interaktywnie, dodaj polecenia `ulimit` do `/etc/profile` (ogólnosystemowy) lub `~/.bashrc` / `~/.profile` (dla konkretnego użytkownika). To podejście jest odpowiednie dla stacji roboczych deweloperów, ale nie nadaje się dla procesów demonów.

Profile konfiguracji `ulimit` oparte na rolach

Różne role serwerów wymagają zasadniczo różnych profili limitów zasobów. Stosowanie ogólnych wartości domyślnych dla wszystkich typów serwerów jest częstym źródłem subtelnych, trudnych do zdiagnozowania awarii.

Serwer WWW (Nginx / Apache)

“`

nofile: 65536–131072 # High concurrency requires many open sockets + files

nproc: 4096 # Worker processes + threads

core: 0 # Disable core dumps in production

“`

Relacyjna baza danych (PostgreSQL / MySQL)

“`

nofile: 65536 # Many concurrent connections = many file descriptors

memlock: unlimited # Required for shared memory and huge pages

nproc: 4096

stack: 8192 KB

core: 0

“`

Serwer aplikacji Java (Tomcat / Spring Boot)

“`

nofile: 65536

nproc: 65536 # JVM thread-per-connection models spawn many threads

data: unlimited # JVM heap is allocated from the data segment

stack: 512 KB # Reduce stack size to fit more threads in memory

“`

Redis / magazyn danych w pamięci

“`

nofile: 65536

memlock: unlimited # Prevents swapping of memory-mapped data

“`

Krytyczne pułapki i przypadki brzegowe

Limit `nproc` liczy wątki, a nie tylko procesy. W systemie Linux wątki są implementowane jako lekkie procesy (`clone()` ze współdzieloną pamięcią). Aplikacja Java z 500 wątkami liczy się jako 500 w stosunku do limitu `nproc`. To zaskakuje wielu administratorów, którzy ustawiają konserwatywne wartości `nproc` i zastanawiają się, dlaczego ich JVM ulega awarii z błędem `OutOfMemoryError: unable to create new native thread`.

`ulimit -v` ogranicza wirtualną przestrzeń adresową, a nie fizyczną pamięć RAM. Wielu administratorów ustawia `-v` myśląc, że ograniczają zużycie pamięci. W rzeczywistości ograniczają wirtualną przestrzeń adresową, która obejmuje pliki mapowane w pamięci, biblioteki współdzielone i metaprzestrzeń JVM. Ustawienie zbyt niskiej wartości spowoduje błędy `mmap()` i niejasne błędy aplikacji.

`ulimit` nie działa wstecznie. Zmiana limitów w `limits.conf` lub pliku jednostki systemd nie wpływa na już działające procesy. Musisz ponownie uruchomić usługę, aby nowe limity weszły w życie.

Środowiska kontenerowe omijają `ulimit` w nieoczekiwany sposób. W Docker domyślne wartości `ulimit` są ustawiane na poziomie demona (`/etc/docker/daemon.json`) i mogą być nadpisywane dla każdego kontenera za pomocą `–ulimit`. Jednak limity kontenera są ograniczone przez limity jądra hosta. Ustawienie `nofile=1048576` w kontenerze, gdy host ma `nofile=65536`, po cichu cofnie się do limitu hosta.

Ogólnosystemowy sufit `nofile` jest oddzielny od limitów per-proces. Parametr jądra `fs.file-max` (ustawiany przez `sysctl`) kontroluje całkowitą liczbę deskryptorów plików w całym systemie. Nawet jeśli `nofile` per-proces jest ustawiony wysoko, osiągnięcie `fs.file-max` spowoduje błędy `ENFILE` w całym systemie. Sprawdź i dostosuj oba:

“`bash

sysctl fs.file-max

sysctl -w fs.file-max=2097152

“`

`ulimit` a cgroups: wybór właściwego narzędzia

`ulimit` pozostaje właściwym narzędziem do szybkich limitów per-sesja, limitów deskryptorów plików i kontroli zrzutów pamięci. Do kompleksowej izolacji zasobów — szczególnie w środowiskach wielodostępnych lub obciążeniach kontenerowych — cgroups v2 jest lepszym mechanizmem. W dobrze skonfigurowanym środowisku Hostingu VPS lub Serwera Dedykowanego, oba mechanizmy są zazwyczaj używane w połączeniu: `ulimit` dla zabezpieczeń per-proces i cgroups dla zbiorczych budżetów zasobów.

Monitorowanie i weryfikacja limitów zasobów

Proaktywne monitorowanie zapobiega przekształcaniu się awarii związanych z limitami w incydenty produkcyjne.

Sprawdzanie bieżącego użycia deskryptorów plików w całym systemie:

“`bash

cat /proc/sys/fs/file-nr

Output: <allocated> <unused> <max>

“`

Znajdowanie procesów zbliżających się do granicy `nofile`:

“`bash

for pid in /proc/[0-9]*; do

pid_num=${pid##*/}

limit=$(awk '/Max open files/{print $4}' /proc/$pid_num/limits 2>/dev/null)

current=$(ls /proc/$pid_num/fd 2>/dev/null | wc -l)

[ -n "$limit" ] && [ "$limit" != "unlimited" ] &&

awk -v c=$current -v l=$limit -v p=$pid_num

'BEGIN{if(c/l>0.8) printf "PID %s: %d/%d (%.0f%%)n",p,c,l,c/l*100}'

done

“`

Narzędzia do bieżącego monitorowania:

• `lsof -u <username>` — lista wszystkich otwartych plików dla użytkownika
• `ss -s` — statystyki gniazd (koreluje z presją `nofile`)
• `htop` z widokiem drzewa procesów — wizualizacja liczby procesów na użytkownika
• `sar -v` — historyczne użycie deskryptorów plików i i-węzłów przez sysstat
• Prometheus `node_exporter` — udostępnia metryki `node_filefd_allocated` i `node_filefd_maximum` do alertowania

W środowiskach z VPS z cPanel lub innymi panelami sterowania, wiele z tych limitów jest wstępnie skonfigurowanych przez instalator panelu, ale często wymagają zwiększenia wraz ze wzrostem ruchu. Zawsze weryfikuj rzeczywiste limity przez `/proc/<PID>/limits`, a nie ufaj dokumentacji panelu.

Implikacje bezpieczeństwa `ulimit`

Limity zasobów są również mechanizmem kontroli bezpieczeństwa. Bez nich skompromitowany lub błędny proces może wykonać bombę fork (`:(){ :|:& };:`), wyczerpując wszystkie dostępne sloty procesów i czyniąc system nieresponsywnym. Konserwatywny limit `nproc` na użytkownika jest podstawowym środkiem zaradczym:

“`

• hard nproc 4096

“`

Podobnie wyłączenie zrzutów pamięci (`-c 0`) zapobiega zapisywaniu wrażliwych treści pamięci — w tym kluczy szyfrowania, haseł i tokenów sesji — do pliku dostępnego do odczytu przez wszystkich.

W środowiskach hostingu współdzielonego lub na każdym serwerze, gdzie wielu użytkowników ma dostęp do powłoki, `ulimit` jest obowiązkową warstwą bezpieczeństwa. W infrastrukturze Hostingu Współdzielonego limity te są zazwyczaj egzekwowane na poziomie platformy, ale administratorzy prowadzący własny wieloużytkownikowy VPS powinni skonfigurować je jawnie.

Jeśli Twój serwer obsługuje terminację SSL lub zarządzanie certyfikatami, upewnij się, że proces obsługujący TLS (np. Nginx, HAProxy) ma wystarczające limity `nofile`, ponieważ każde połączenie TLS wymaga wielu deskryptorów plików. Połącz to z prawidłowo skonfigurowanymi Certyfikatami SSL, aby uniknąć sytuacji, w której problemy związane z certyfikatami potęgują problemy z zasobami.

W przypadku wdrożeń serwerów pocztowych, Postfix i Dovecot są szczególnie wrażliwe na limity `nofile`, ponieważ każde równoczesne połączenie e-mail i dostęp do skrzynki pocztowej zużywa deskryptory plików. Jeśli prowadzisz własną infrastrukturę pocztową zamiast korzystać z zarządzanego Hostingu Poczty, dostrojenie `nofile` do co najmniej 65536 dla użytkownika poczty jest bezwzględnie konieczne na każdym umiarkowanie obciążonym serwerze.

Macierz decyzyjna: co konfigurować i gdzie

Techniczna lista kontrolna kluczowych wniosków

• Zawsze weryfikuj zastosowane limity przez `/proc/<PID>/limits`, a nie `ulimit -a` na poziomie powłoki, dla działających usług.
• Dla usług systemd konfiguruj limity w pliku jednostki używając dyrektyw `Limit*` — `limits.conf` nie jest domyślnie odczytywany przez systemd.
• Ustaw `nofile` na co najmniej `65536` dla każdej usługi obsługującej połączenia sieciowe; `131072` lub więcej dla obciążeń o wysokiej współbieżności.
• Nigdy nie ustawiaj limitu twardego równego limitowi miękkiemu, chyba że masz konkretne wymagania bezpieczeństwa — aplikacje potrzebują przestrzeni do samodzielnego dostosowania.
• Wyłącz zrzuty pamięci (`LimitCORE=0`) w środowisku produkcyjnym; włącz je z kontrolowaną ścieżką w środowisku testowym.
• Limit `nproc` liczy wątki w systemie Linux — uwzględnij to przy konfiguracji aplikacji JVM lub środowiska uruchomieniowego Go.
• Dostrajaj `fs.file-max` przez `sysctl` wraz z limitami `nofile` per-proces, aby uniknąć wyczerpania `ENFILE` w całym systemie.
• W środowiskach kontenerowych limity jądra hosta są twardym sufitem — ustawienia `ulimit` na poziomie kontenera nie mogą ich przekroczyć.
• Używaj cgroups v2 do egzekwowania pamięci i I/O; używaj `ulimit` do limitów deskryptorów plików, liczby procesów i kontroli zrzutów pamięci.
• Po każdej zmianie limitu w `limits.conf` lub plikach jednostek systemd, uruchom ponownie usługę i zweryfikuj za pomocą `/proc/<PID>/limits`.

FAQ

Czy `ulimit` dotyczy procesów roota?

Symbol wieloznaczny `*` w `/etc/security/limits.conf` jawnie wyklucza roota. Procesy roota omijają również egzekwowanie twardych limitów dla większości typów zasobów — root może podnosić własne twarde limity. Aby zastosować limity do roota, dodaj jawny wpis `root` w `limits.conf`, choć wiele usług systemowych działających jako root zignoruje limity zastosowane przez PAM, jeśli zostały uruchomione poza sesją logowania.

Dlaczego moja zmiana `limits.conf` nie ma wpływu na działającą usługę?

`limits.conf` jest stosowany przez PAM w czasie logowania. Usługi uruchamiane przez systemd, SysVinit lub Upstart nie przechodzą przez PAM i dlatego nie dziedziczą ustawień `limits.conf`. Konfiguruj limity bezpośrednio w pliku jednostki systemd używając `LimitNOFILE` i powiązanych dyrektyw, a następnie uruchom `systemctl daemon-reload && systemctl restart <service>`.

Jaka jest maksymalna wartość, jaką mogę ustawić dla `nofile`?

Maksimum per-proces jest ograniczone przez parametr jądra `fs.nr_open` (domyślnie: 1 048 576 na większości jąder). Całkowita wartość ogólnosystemowa jest ograniczona przez `fs.file-max`. Możesz podnieść `fs.nr_open` przez `sysctl`, ale wartości powyżej 1 048 576 wymagają rekompilacji jądra na starszych jądrach. W praktyce 524 288 lub 1 048 576 pokrywa praktycznie wszystkie przypadki użycia produkcyjnego.

Jak sprawdzić, czy proces osiągnął granicę `ulimit`?

Sprawdź dziennik jądra za pomocą `dmesg | grep -i "ulimit|RLIMIT|too many open|cannot allocate"`. Dzienniki aplikacji zazwyczaj pokażą `EMFILE` (zbyt wiele otwartych plików), `ENOMEM` (błąd alokacji pamięci) lub `EAGAIN` (zasób tymczasowo niedostępny). Skrzyżuj z `/proc/<PID>/limits` i bieżącą liczbą deskryptorów przez `ls /proc/<PID>/fd | wc -l`.

Czy `ulimit` jest wystarczający do izolacji zasobów w środowisku wielodostępnym?

Nie. `ulimit` zapewnia zabezpieczenia per-proces i per-użytkownik, ale nie egzekwuje limitów przepustowości pamięci, I/O dysku ani przepustowości sieci. Dla prawdziwej izolacji wielodostępnej połącz `ulimit` z kontrolerami zasobów cgroups v2 i rozważ izolację przestrzeni nazw (przestrzenie nazw użytkowników, przestrzenie nazw PID) dla silniejszych granic bezpieczeństwa. W zarządzanej infrastrukturze te mechanizmy kontroli są zazwyczaj nakładane na poziomie hiperwizora i środowiska uruchomieniowego kontenerów.