Externe Integrationen auf SBC ARM ohne CONFIG_CFS_BANDWIDTH-Unterstützung nicht verfügbar (Khadas, möglicherweise Raspberry Pi)

Entwicklung
1

Hallo,

Ich melde ein blockierendes Problem für alle externen Integrationen auf meinem Khadas VIM1S (Ubuntu 24.04, Kernel Amlogic 7.0.0+).

Symptom — Externe Integrationen können nicht gestartet werden (getestet mit Shelly), Fehler in den Logs:

Cannot restart container XXX: ... error setting cgroup config for procHooks process: 
openat2 /sys/fs/cgroup/.../cpu.max: no such file or directory

Isolierte Ursache, reproduzierbar außerhalb von Gladys:

bash

docker run --rm hello-world              # OK
docker run --rm --cpus="1.0" hello-world # scheitert mit demselben Fehler

Kernel-Bestätigung :

bash

cat /boot/config-$(uname -r) | grep CFS_BANDWIDTH
→ CONFIG_CFS_BANDWIDTH is not set

Diese Kernel-Kompilierungsflagge stellt cpu.max (CPU-Quota cgroup v2) bereit. Ohne diese kann keine --cpus-Grenze auf einen Container gesetzt werden — daher scheitern externe Integrationen, sobald diese Grenze bei der Erstellung angewendet wird, systematisch und ohne die Möglichkeit eines Workarounds auf Systemkonfigurationsebene (getestet: cgroup-Treiber systemd und cgroupfs, cgroup-Delegierung auf allen Ebenen als korrekt überprüft).

Potenzielle Reichweite: Dies ist nicht auf meine Hardware beschränkt. Der Raspberry Pi hatte historisch dasselbe Problem (Ticket raspberrypi/linux#3387, immer noch offen).

Vorschlag: Die CPU-Grenze optional machen oder auf --cpu-shares (Gewichtung, erfordert nicht cpu.max) umstellen, anstatt eine strikte Quote zu verwenden — oder das Fehlen von cpu.max erkennen und den Container ohne Grenze erstellen, anstatt zu scheitern.

Ich stehe für Tests auf dieser Hardware zur Verfügung, falls benötigt. Danke.

2

Willkommen im Forum, @Didier_Hilary!

Ähnelt dein Problem nicht dem, das wir mit den Synology-Geräten hatten?

Falls ja, werden wir deinen Beitrag in einen Feature-Request umwandeln, um auch andere Geräte zu berücksichtigen.

3

Guten Abend,

Das Problem scheint nicht genau dasselbe zu sein, der folgende Befehl gibt die richtige Syntax aus, wenn ich das Problem mit Synology richtig verstehe!!

khadas@Khadas:~$ docker info --format ‹ {{json .}} › | python3 -m json.tool | grep -i cfs
« CpuCfsPeriod »: true,
« CpuCfsQuota »: true,

Vielleicht liegt das Problem an meinem System, es verarbeitet die Quoten nicht richtig!!

Gibt es eine Möglichkeit, diesen Quotenmechanismus auf Ebene der Gladys-Integrationen zu deaktivieren?
Danke

Mit freundlichen Grüßen

4

@pierre-gilles hast du dieses Problem schon mal gesehen?

5

Ich habe Fable darauf gestartet

6

Hallo zusammen!

Dieses Thema ist nun in Entwicklung.

Ein PR wurde eröffnet, um externe Integrationen auf Kernels ohne CFS-Bandbreitenunterstützung zu starten:

Zögert nicht, dem PR zu folgen, zu testen (optional, vor allem für kleine Anfragen) und euer Feedback hier zu hinterlassen, falls nötig.

7

Hallo @Didier_Hilary,

Ich schlage dir einen arm64-Build zum Testen dieses Fixes vor:

ghcr.io/gladysassistant/gladys-preview:claude-external-integrations-arm-unavailable-qk4lsh-arm64

Du kannst zum Beispiel mit diesem Befehl testen (Achtung bei den Docker-Volumes, dem Port, denk daran, diesen Befehl entsprechend deiner Installation anzupassen):

sudo docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --cgroupns=host \
  --restart=always \
  --privileged \
  --network=host \
  --name gladys-claude-external-integrations-arm-unavailable-qk4lsh-arm64 \
  -e NODE_ENV=production \
  -e SERVER_PORT=80 \
  -e TZ=Europe/Paris \
  -e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /var/lib/gladysassistant:/var/lib/gladysassistant \
  -v /dev:/dev \
  -v /run/udev:/run/udev:ro \
  ghcr.io/gladysassistant/gladys-preview:claude-external-integrations-arm-unavailable-qk4lsh-arm64
8

Ich habe den Fix auch in der Version 5.0.1 bereitgestellt:

9

Hallo,

Mit Version 5.0.1 gelingt es mir, den Dienst auf der Maschine zu installieren :slight_smile:

Aber trotz allem habe ich nicht bemerkt, dass meine Module Shelly Gen1 sind und daher nicht in Gladys integrierbar sind!!

Ich habe ein weiteres Infrastrukturproblem auf meinem Khadas VIM1S entdeckt, das gemeldet werden sollte, da es potenziell alle externen Integrationen im isolierten Bridge-Netzwerk betrifft, nicht nur Shelly.

Das Symptom

Ein Container für externe Integration (Netzwerk gladys-integrations, isoliertes Bridge 172.30.0.0/24) kann keine Geräte im LAN erreichen — systematisches Timeout beim Verlassen, während der Host selbst diese Geräte problemlos kontaktiert.

Die Ursache: Mein Kernel unterstützt kein NAT-Backend

bash

docker run --rm --network gladys-integrations curlimages/curl http://<IP_LAN> --max-time 5
# → timeout

Bei genauerer Betrachtung:

  • nftables fehlt: CONFIG_NF_TABLES is not set im Kernel
  • iptables-legacy fehlt ebenfalls: Das Modul ip_tables existiert ebenfalls nicht (modprobe: FATAL: Module ip_tables not found)

Daher kann Docker keine NAT/SNAT-Regeln erstellen, unabhängig vom Backend — Container im isolierten Bridge können niemals das LAN erreichen. Deshalb war "iptables": false bereits in meiner daemon.json konfiguriert (wahrscheinlich, um Docker überhaupt zu starten, mangels funktionellem NAT-Backend) — aber dieser Workaround verhindert genau das NAT, das die externen Integrationen benötigen.

Warum dies potenziell andere Benutzer betrifft

Es handelt sich um einen Kernel des Herstellers (Amlogic, stark reduziert, ursprünglich für Android-TV-Boxen ausgelegt), dem mehrere Standard-Netzwerk-/cgroup-Komponenten fehlen. Angesichts der Anzahl der leichten ARM-SBCs, die in der Smart-Home-Community verwendet werden (umgerüstete TV-Boxen, günstige ARM-Mini-PCs usw.), ist dies wahrscheinlich kein Einzelfall.

Vorschlag

Für externe Integrationen, die LAN-Geräte kontaktieren müssen (wie Shelly, Tasmota usw. — alles, was nicht rein MQTT über den Host ist), wäre es möglich, eine Konfigurationsoption im Host-Netzwerkmodus anzubieten, anstatt im isolierten Bridge? Dies würde den NAT-Bedarf für Benutzer umgehen, deren System dies nicht unterstützt, mit der üblichen Sicherheitswarnung (reduzierte Isolation).

Ich stehe für Tests zur Verfügung, falls benötigt.

10

Hallo Didier!

Vielen Dank für diese Untersuchung, es ist super präzise und hilft sehr. :folded_hands:

Du hast den wahren Grund gefunden: Dein Kernel ist ohne Netfilter kompiliert (CONFIG_NF_TABLES is not set, keine iptables). Doch Netfilter ist es, das den NAT der Docker-Bridge-Netzwerke macht — ohne ihn kann kein Container im Bridge-Modus das LAN erreichen, egal welche Anwendung. Es handelt sich also nicht um eine Einschränkung von Gladys: Auf diesem Kernel ist das Docker-Netzwerk unter unseren Füßen kaputt (der offizielle Docker-check-config.sh-Script markiert diese Optionen übrigens als erforderlich).

Was network=host betrifft, möchte ich transparent sein: Das wird keine Option in Gladys sein. Das gesamte Sicherheitsmodell der externen Integrationen basiert auf der Netzwerkisolation: Eine Integration kann nicht auf die lokalen Dienste deines Computers zugreifen, kann nicht mit anderen Integrationen kommunizieren, und die Netzwerkentdeckung erfolgt über einen expliziten Vertrag, den du bei der Installation genehmigst. Mit dem Host-Modus verschwinden alle diese Garantien — und „mit einer Warnung“ hält nicht lange: Sobald eine beliebte Integration dies erfordert, wird die Warnung zu einem Reflexklick und die Zusage „eine Integration kann nicht X tun“ ist wertlos. Ein Detail, das wichtig ist: Ohne Netfilter wird die Isolation zwischen Containern (enable_icc=false) ohnehin nicht angewendet — also auf diesem Kernel könnten wir unsere Garantien auch ohne Host-Modus nicht einhalten.

Die gute Nachricht: Es ist auf der OS-Seite reparierbar und sauber. :tada:

  1. Überprüfe zunächst, ob die Module existieren, aber nicht geladen sind: sudo modprobe nf_tables und dann ls /lib/modules/$(uname -r)/kernel/net/netfilter/. Aufgrund deines CONFIG_NF_TABLES is not set ist das unwahrscheinlich, aber es lohnt sich für 30 Sekunden.
  2. Die Lösung, die ich dir empfehle: Wechsel zu Armbian für deinen VIM1S. Es gibt offizielle und gewartete Armbian-Images für den Khadas VIM1S, mit einem Kernel, der Netfilter enthält. Docker (Bridge, NAT, Isolation) funktioniert normal darauf. Denke daran, vor dem Wechsel eine Gladys-Sicherung zu erstellen, du kannst sie auf der neuen Installation wiederherstellen.
  3. Alternativ kannst du das Problem an Khadas melden: Es gibt bereits Tickets zu diesem Thema in ihrem Build-Tool (fenix #297, fenix #68) — die fehlenden Netfilter-Module in ihren Vendor-Kernels sind ein bekanntes Problem bei ihnen.

Lass mich wissen, wenn du Armbian ausprobierst, dein Feedback wird allen helfen, die SBCs mit leichten Vendor-Kernels verwenden! :blush:

11

Guten Abend,

Ich bin auf Armbian migriert und habe Gladys neu installiert, alles funktioniert einwandfrei. Ich habe die Shelly-Unterstützung installiert und es hat mein Shelly 2.5 Gen1-Modul entdeckt. Ich erhalte die vom Modul gesendeten Informationen, kann die Relais mit der Integration jedoch nicht steuern.

Vielen Dank für die Information zu Armbian

Freundliche Grüße

Installierte Version:

PRETTY_NAME=« Armbian 26.8.3 noble »
NAME=« Ubuntu »
VERSION_ID=« 24.04 »
VERSION=« 24.04 LTS (Noble Numbat) »
VERSION_CODENAME=noble
ID=ubuntu