[V4.5] PSA_Car_controller funktioniert in Portainer nicht mehr
Verfasst: So Nov 09, 2025 2:34 pm
Ich nutzte den PSA Car Controller (https://github.com/flobz/psa_car_contro ... /Docker.md) bisher ohne Probleme, jetzt hat PSA mal wieder die Schnittstelle geändert und PSA Controller wurde upgedatet und auch der Container in dockerhub. Allerdings habe ich massiv Probleme mit dieser neuen Version und bekomme sie nicht mehr ans Laufen:
Laut KI stellt sich hier wohl ein Problem mit multithreads die wohl neu im PSA Controller eingeführt wurden, Antwort der KI:
Kann hier seitens TWS ein solches Threadlimit erweitert werden bzw. dieser Container "whitelisted" oder ein spezifisches seccomp Profil zugewiesen werden wie vorgeschlagen? Oder gibt es andere Lösungsmöglichkeiten einen solchen multithread Container auf dem TWS zum laufen zu bekommen?
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.