Docker Systemlimits erhöhen: inotify-Limits richtig setzen

Stand: 11.10.2026

Wenn Docker mit too many open files oder inotify_init: too many open files scheitert, musst Du zuerst die erreichte Grenze ermitteln. Docker Systemlimits erhöhen bedeutet nicht, pauschal riesige Werte zu setzen. Entscheidend ist, ob das Prozesslimit, das systemweite Dateihandle-Limit oder ein inotify-Limit greift.

Auf einen Blick

• fs.file-max begrenzt Dateihandles systemweit; ulimit -n betrifft einen Prozess.
• inotify-Watches, -Instanzen und die Warteschlange sind getrennte Grenzen.
• Prüfe Verbrauch und Fehlermeldung, bevor Du einen sysctl-Wert dauerhaft änderst.
• Für Docker-Dienste setzt Du LimitNOFILE= gezielt im systemd-Drop-in.

Welche Docker Systemlimits erhöhen musst Du wirklich?

Eine Datei kann mehrere Grenzen berühren. Der Kernel begrenzt mit fs.file-max, wie viele Dateihandles er insgesamt vergeben darf. Das ist nicht dasselbe wie die maximale Zahl offener Dateien eines einzelnen Prozesses. Diese Prozessgrenze heißt RLIMIT_NOFILE und erscheint in der Shell als ulimit -n.

inotify überwacht Änderungen im Dateisystem. Entwicklungsserver, IDEs, Synchronisationsdienste und Monitoring können viele Watches anlegen. Erscheint im Log No space left on device bei inotify, meint das oft keine volle Festplatte, sondern ein inotify-Limit. Deshalb prüfst Du zuerst den konkreten Fehler.

Aktuelle Limits und Nutzung sicher prüfen

Starte mit einer Bestandsaufnahme auf dem Host. Die Ausgabe von file-nr enthält die aktuellen belegten Dateihandles und als dritten Wert das Maximum. Der Kernel dokumentiert fs.file-max als maximale Zahl der Dateihandles, die er allokiert.

# Systemweite Dateihandle-Grenze und Nutzung
sysctl fs.file-max
cat /proc/sys/fs/file-nr

# inotify-Grenzen
sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances
sysctl fs.inotify.max_queued_events

# Grenze der aktuellen Shell
ulimit -Sn
ulimit -Hn

Prüfe danach den betroffenen Container. Nutze sh statt bash, weil schlanke Images Bash oft nicht enthalten. Der Wert im Container kann vom Host abweichen, wenn Docker beim Start ein anderes ulimit erhalten hat.

docker exec <container> sh -c 'ulimit -n; cat /proc/1/limits'
docker inspect <container> --format '{{json .HostConfig.Ulimits}}'

Außerdem lohnt sich ein Blick in die Anwendung. Ein Leak offener Dateien löst Du nicht dauerhaft, indem Du nur das Limit anhebst. Für einen Überblick über laufende Prozesse helfen lsof -p <PID> und /proc/<PID>/fd.

inotify-Limits dauerhaft konfigurieren

Lege eine eigene Datei unter /etc/sysctl.d/ an. Das ist robuster als mehrfaches Anhängen an /etc/sysctl.conf, weil die Einstellung klar zuzuordnen und beim Konfigurationsmanagement einfach zu verwalten ist. Wähle Werte anhand der gemessenen Last; die folgenden Werte sind ein Beispiel, keine Pflicht für jedes System.

1. Lege die Konfiguration mit nachvollziehbarem Namen an.
2. Lade die sysctl-Konfiguration.
3. Prüfe anschließend die wirksamen Werte.

sudo tee /etc/sysctl.d/60-inotify.conf
# Inhalt der Datei:
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 1024

sudo sysctl --system
sysctl fs.inotify.max_user_watches fs.inotify.max_user_instances

Die Watch-Grenze gilt pro Benutzerkennung. Eine Watch benötigt Kernel-Speicher; daher solltest Du sie nicht ohne Bedarf extrem hoch setzen. Wenn Ereignisse verloren gehen, kann zusätzlich fs.inotify.max_queued_events relevant sein. Dann prüfst Du zuerst, ob der Consumer die Ereignisse schnell genug verarbeitet.

Wann ist fs.file-max sinnvoll?

fs.file-max betrifft das gesamte System. Die Linux-Kernel-Dokumentation empfiehlt eine Erhöhung erst bei Meldungen über ausgeschöpfte File-Handles. Ein hoher Wert ersetzt weder ein passendes Prozesslimit noch die Suche nach einem FD-Leak.

Wenn die systemweite Grenze nachweislich zu klein ist, speicherst Du die Änderung getrennt. So bleibt klar, welche Anpassung für welches Problem vorgenommen wurde.

sudo tee /etc/sysctl.d/61-file-handles.conf
# Inhalt der Datei:
fs.file-max = 2097152

sudo sysctl --system
sysctl fs.file-max
cat /proc/sys/fs/file-nr

Beachte auch fs.nr_open: Dieser Kernelwert begrenzt das maximale RLIMIT_NOFILE eines einzelnen Prozesses. Ein größerer LimitNOFILE-Wert kann daher nicht beliebig über fs.nr_open liegen.

Docker und systemd mit LimitNOFILE richtig einstellen

Docker startet Container mit den Limits, die der Daemon erbt oder die Du beim Containerstart explizit vorgibst. Auf systemd-Systemen ist ein Drop-in für den Docker-Dienst die saubere Stelle. Die systemd-Dokumentation nennt für Dienste standardmäßig DefaultLimitNOFILE=1024:524288; ein Dienst kann dies mit LimitNOFILE= überschreiben.

sudo systemctl edit docker.service

# Im Editor eintragen:
[Service]
LimitNOFILE=65536

sudo systemctl daemon-reload
sudo systemctl restart docker
systemctl show docker --property=LimitNOFILE

Der Neustart unterbricht Container. Plane ihn deshalb ein und prüfe den Betrieb anschließend. Soll nur ein einzelner Container mehr Datei-Deskriptoren erhalten, ist ein explizites Ulimit besser als eine globale Erhöhung.

docker run --ulimit nofile=65536:65536 <image>

Für Compose gehört die Einstellung in den jeweiligen Service. Damit bleibt sie versioniert und betrifft keine anderen Workloads. Wenn Du mehrere Dienste betreibst, helfen Dir auch unsere Anleitungen zu Docker Compose, zu Docker-Healthchecks und zu Monitoring mit Grafana Alloy.

Welche Änderung löst welches Problem?

Arbeite in dieser Reihenfolge: Fehler sichern, Limit und Verbrauch messen, die kleinste passende Grenze ändern und danach erneut testen. So verhinderst Du, dass ein kaputtes Anwendungsmuster unbemerkt nur mehr Ressourcen erhält.

1. Suche im Log nach der exakten Fehlermeldung und notiere Prozess oder Container.
2. Prüfe Prozesslimits, file-nr und die drei inotify-Werte.
3. Ändere entweder die sysctl-Datei, den systemd-Drop-in oder das Container-Ulimit.
4. Lade die Konfiguration, starte nur nötige Dienste neu und kontrolliere die Werte erneut.
5. Beobachte Logs und offene Deskriptoren nach der Änderung.

Fazit

Docker Systemlimits erhöhen ist eine gezielte Diagnoseaufgabe. fs.file-max schützt das gesamte System, LimitNOFILE begrenzt Dienste und inotify-Werte steuern Dateiwatcher. Wenn Du Fehler, Nutzung und wirksame Limits zuerst vergleichst, setzt Du nur die notwendige Änderung und behältst Docker-Workloads kontrollierbar.

Quellen

• Linux Kernel: /proc/sys/fs
• inotify(7)
• systemd-system.conf: DefaultLimitNOFILE
• Docker Docs: Resource constraints

Häufige Fragen