Ulimit (User Limit)

Anzeigen: ulimit -a (Zeigt alle Limits). ulimit -n (Anzahl offener Dateien, oft 1024 - zu wenig für Webserver!).

Setzen (temporär): ulimit -n 65535

Setzen (dauerhaft): In /etc/security/limits.conf:

* soft nofile 4096
* hard nofile 65535

1. Soft vs. Hard Limit

• Soft Limit: Die Warnschwelle. Der User kann dieses Limit selbst hochsetzen (bis zum Hard Limit).
• Hard Limit: Die absolute Decke. Nur Root kann das Hard Limit erhöhen. Sicherheit: Ein Hacker kann sein Soft Limit nicht über das Hard Limit pushen, um den Server zu DoSen.

2. Fork Bomb Protection (nproc)

Ein klassischer Angriff: :(){ :|:& };: (Bash Fork Bomb). Eine Funktion, die sich selbst 2x aufruft. Exponentiales Wachstum. Binnen Sekunden hat der Server 100.000 Prozesse und friert ein. Lösung: ulimit -u 1000 (Max User Processes). Die Bombe stoppt bei 1000 Prozessen. Der Admin kann sich noch einloggen und killen.

3. "Too many open files"

Der häufigste Fehler bei High-Performance Servern (Nginx, Kafka, DBs). Jede Netzwerkverbindung (Socket) ist in Linux eine "Datei". Standard-Limit ist oft 1024. Wenn 1025 User auf deine Webseite zugreifen, crasht Nginx. Für Production immer auf 65535 oder höher setzen (und fs.file-max im Sysctl prüfen).

PAM (Pluggable Authentication Modules) und Login-Limits

Der Linux-Kernel kennt keine Dateiparser für /etc/security/limits.conf. Wie greifen diese Konfigurationen also dann? Das Geheimnis liegt bei PAM. Wenn ein User sich via SSH einloggt oder su ausführt, durchläuft der Prozess den pam_limits.so Modul-Hook. Dieses C-Modul parst die Datei, ruft den setrlimit() System-Call im Linux Kernel auf und weist dem Child-Prozess der neuen Bastion-Shell die ulimits zu. Problem: Systemd-Services (wie ein Nginx Daemon) durchlaufen den alten PAM-Login-Prozess gar nicht! Deshalb interessieren limits.conf Werte einen Docker-Container oder einen systemctl start apache2 komplett null. Für Daemons muss man in systemd zwingend z.B. LimitNOFILE=65535 in der Service-Unit verankern, was Systemd vor Aufruf des ExecStarts an den Kernel durchreicht.

File Descriptor (FD) Leaks aufspüren

"Too many open files" heißt nicht zwingend "Du bist zu erfolgreich für deinen Server". In 90% der Fälle ist es ein Programmierfehler. Entwickler öffnen im Backend Sockets (Socket s = new Socket(...)) oder File-Streams, und vergessen im catch-Block den .close() Call. Jeder vergessene Handle "leakt" einen Deskriptor. Die C-Library des OS allokiert dafür unweigerlich Inodes. Zur Jagd auf diese Bugs geht man auf OS-Ebene: lsof -p <PID> | wc -l zählt die Live-Deskriptoren eines Prozesses. Sieht dieser Counter wie ein unendlich steigendes Treppenmuster (Sägezahn) aus, ist es ein FD-Leak. Der Prozess hält alte Connections, bis Linux ihn bei Deskriptor 65.535 rigoros und panisch vom RAM exekutiert.

NPROC und der Apache/PHP-FPM Tod

Das Limit u -nproc (Maximum User Processes) hat eine gewaltige Tücke: Es gilt global für den physischen Linux-Benutzer (UID), akkumuliert über alle Sessions hinweg. Lässt man 50 PHP-FPM Webseiten isoliert und sauber getrennt im Host laufen, verwendet aber fatalerweiße aus Bequemlichkeit unter der Haube alle via UID www-data ... schlägt NPROC zu. Sobald Prozess-Pool Nr. 15 hochskaliert (durch Traffic) und über das globale 1024 Limit stolpert, reißt der Kernel alle anderen 35 fremden Kunden-Webseiten schlagartig mit ins "Internal Server Error" Verderben, da Linux www-data am Starten jeder weiteren Fork/Thread verweigert. Sauberes Ulimit Handling erfordert strickt getrennte Exec-User (e.g., php-user-1).