Laut KI stellt sich hier wohl ein Problem mit multithreads die wohl neu im PSA Controller eingeführt wurden, Antwort der KI:
Code: Alles auswählen
Die Ausgabe von ulimit -a zeigt, dass für "max user processes" (-u) und andere Limits im Container keine sichtbaren Beschränkungen existieren: alle sind auf "unlimited" gesetzt. Das bedeutet, klassisch betrachtet dürfte der Container beliebig viele Threads und Prozesse starten.
Trotzdem erhältst du den Fehler RuntimeError: can't start new thread, was darauf hindeutet, dass das Timberwolf-System die Thread-Erstellung auf anderer Ebene blockiert:
Interpretation der Limits
max user processes (-u) unlimited: Es existiert kein hartes Prozesslimit für den User im Container.
open files (-n) 1048576: Sehr hoch, kein typisches Limit-Problem.
stack size: 8192 kB, ausreichend für Standardapplikationen.
Insgesamt sind keine klassischen Kernel- oder User-Limits auf Prozesse/Threads gesetzt.
Wahrscheinlicher Grund
Die eigentliche Restriktion erfolgt nicht durch ulimit, sondern wahrscheinlich durch ein Docker-spezifisches Sicherheitsprofil (z.B. seccomp, AppArmor) oder durch Timberwolf-spezifische Container-Policies.
Diese blockieren gezielt den System-Call für Thread-Erstellung (pthread_create) und nicht die grundsätzliche Prozess-Anzahl über ulimit.
Auch mit "unlimited" als ulimit kannst du in so einer Umgebung trotzdem keine neuen Threads erzeugen.
Bestätigende Symptome
Die Fehler und Logs aus deinem psa_car_controller sowie OpenBLAS-Test zeigen, dass Python und OpenBLAS beim Versuch, neue Threads zu starten, einen Operation not permitted oder can't start new thread auslösen – das spricht für ein höheres Sicherheits-Layer als ulimit.
Das ist typisch bei Embedded-Systemen, die Docker gezielt härten, um Instabilität oder Missbrauch zu verhindern (beim Timberwolf vermutlich eine Kernel- oder Docker-native Policy).
Mögliche nächste Schritte
Prüfe explizit die Docker/Kernel Sicherheitssteuerung:
Schaue, ob im Timberwolf-System spezielle Profile aktiv sind (seccomp, AppArmor, SELinux).
Falls möglich, lasse dir das aktuelle seccomp-Profil für deinen Container anzeigen.
Portainer/Timberwolf Logs durchsuchen:
Eventuell findest du in den Timberwolf- oder Docker-Kernel-Logs (z.B. dmesg, /var/log/messages) Hinweise darauf, warum Thread-Erstellung verboten wird.
Timberwolf-Support oder Community kontaktieren:
Das Verhalten ist systemseitig so konfiguriert und aus Sicherheitsgründen gefixt.
Du kannst bei Timberwolf oder im Forum gezielt nach einer Lösung fragen ("Kann man ein seccomp-Profil für Python/psa_car_controller zuweisen?").
Fazit
Das Thread-Limit entsteht auf einer Ebene, die mit ulimit nicht geprüft oder überschrieben werden kann. Die ausgegebene Beschränkung wird mit hoher Wahrscheinlichkeit durch Timberwolf-spezifische Container- oder Docker-Sicherheitsrichtlinien (seccomp o.Ä.) erzeugt und blockiert die Funktionalität vieler Python-Anwendungen. Ohne Änderung dieser Richtlinie am System selbst gibt es technisch keinen Workaround auf Container-Ebene.
