Ein Dienst kann keine weiteren Threads oder Prozesse erzeugen · Linux Fix Lab

Symptome und Geltungsbereich

Der Kernel meldet fork rejected by pids controller.
Ein Worker-Pool oder eine Shell kann keine weiteren Aufgaben erzeugen.

Betroffene Umgebung

Linux-cgroup-v2-pids-Controller und systemd-TasksMax; Threads zählen zum Aufgabenbudget.

Erkennbare Meldungen (synthetische Beispiele)

kernel: cgroup: fork rejected by pids controller in /system.slice/example.service

Ein Aufgabenbudget blockierte die Erstellung; prüfe lokale und Elternlimits sowie Threadbedarf.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Dienst oder Elternbereich kann pids.max erreichen; gezählt werden Threads, nicht nur Prozessführer.
Eine Anwendung kann Threads verlieren oder zu viele Worker erzeugen; RLIMIT_NPROC ist eine getrennte mögliche Grenze.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Ersetze die betroffene Unit; liest aktuelle Aufgabenzahl und Grenzen.

systemctl show example.service -p ControlGroup -p TasksCurrent -p TasksMax -p LimitNPROC

Ergebnis einordnen: TasksMax gilt pro cgroup, LimitNPROC pro Benutzerkonto. Ein Elternlimit kann unterhalb des lokalen Dienstmaximums blockieren.

Prüfschritt 2

Ersetze den Pfad durch ControlGroup unter /sys/fs/cgroup; liest vorhandene cgroup-v2-Dateien.

cat /sys/fs/cgroup/system.slice/example.service/pids.current /sys/fs/cgroup/system.slice/example.service/pids.max /sys/fs/cgroup/system.slice/example.service/pids.events

Ergebnis einordnen: Vergleiche Anzahl, Limit und max-Ereignisdifferenzen. Nach Regeländerung kann die Zahl vorübergehend höher liegen; neue Threads überschreiten die wirksame Grenze nicht.

Nächste Schritte nach Befund

Worker- und Thread-Erstellung begrenzen

Wenn die Anzahl mit Verbindungen oder Aufträgen steigt und danach nicht fällt, begrenze den dokumentierten Worker-Pool und untersuche Lebenszykluslecks. Reduziere zugelassene Parallelität statt blinder Neustarts.

Vorsicht: Worker-Stopp oder Neustart kann Anfragen unterbrechen. Sichere Zählerhinweise vor einem Reset.

Wiederherstellung / Rücknahme: Stelle Parallelität nur im vorgesehenen Budget zurück; nutze den unterstützten Rückweg unterbrochener Aufträge.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Vorgesehenes Aufgabenbudget passend wählen

Wenn berechtigter Threadbedarf ein zu niedriges TasksMax übersteigt, erhöhe das endliche Budget dieses Dienstes oder seines begrenzenden Elternbereichs. Prüfe Speicherbedarf und Hostreserve mit weiterhin vorhandener Grenze.

Vorsicht: Nur das Kindlimit zu erhöhen übersteuert den Elternbereich nicht. Unbegrenzte Aufgaben können eine Worker-Schleife verschärfen.

Wiederherstellung / Rücknahme: Stelle Aufgabenbudgets auf ihren ursprünglichen Ebenen zurück und vergleiche dieselbe Verbindungslast.