Intégrations externes indisponibles sur SBC ARM sans support CONFIG_CFS_BANDWIDTH (Khadas, potentiellement Raspberry Pi)

Développement
1

Bonjour,

Je remonte un problème bloquant pour toute intégration externe sur mon Khadas VIM1S (Ubuntu 24.04, kernel Amlogic 7.0.0+).

Symptôme — impossible de démarrer une intégration externe (testé avec Shelly), erreur dans les logs :

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

Cause isolée, reproductible hors Gladys :

bash

docker run --rm hello-world              # OK
docker run --rm --cpus="1.0" hello-world # échoue avec la même erreur

Confirmation kernel :

bash

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

Ce flag de compilation kernel fournit cpu.max (quota CPU cgroup v2). Sans lui, aucune limite --cpus ne peut être posée sur un conteneur — donc dès que les intégrations externes appliquent cette limite à la création, ça échoue systématiquement, sans contournement possible côté config système (testé : cgroup driver systemd et cgroupfs, délégation cgroup vérifiée correcte à tous les niveaux).

Portée potentielle : ce n’est pas isolé à mon matériel. Le Raspberry Pi a eu historiquement le même souci (ticket raspberrypi/linux#3387, toujours ouvert).

Suggestion : rendre la limite CPU optionnelle, ou basculer sur --cpu-shares (pondération, ne nécessite pas cpu.max) plutôt qu’un quota strict — voire détecter l’absence de cpu.max et créer le conteneur sans limite plutôt que d’échouer.

Je reste dispo pour tester sur ce matériel si besoin. Merci

2

Bienvenue sur le forum @Didier_Hilary !

Est-ce que ton problème ne ressemble pas à celui que nous avons eu sur les Synology ?

Si c’est le cas, on transformera ton post en une demande de fonctionnalités pour la prise en compte d’autres machines.

3

Bonsoir,

Le probleme ne semble pas etre exactement le meme, la commande suivante donne bien la bonne syntaxe si je comprends bien le probleme synology!!

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

Peut-etre que le probleme vient de mon systeme, il ne gere pas bien les quotas!!

Y-a-t-il un moyen de desactiver ce mecanisme des quotas au niveau des integrations gladys?
Merci

Cordialement

4

@pierre-gilles tu as déjà vu ce soucis ?

5

J’ai lancé Fable dessus

6

Salut tout le monde !

Ce sujet est désormais en cours de développement.

Une PR a été ouverte pour démarrer les intégrations externes sur les kernels sans support CFS bandwidth :

N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.

7

Salut @Didier_Hilary,

Je te proposes un build arm64 pour tester ce correctif :

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

Tu peux tester par exemple avec cette commande (attention aux volumes Docker, au port, pense bien à modifier cette commande selon ton installation) :

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

J’ai aussi déployé le correctif dans la 5.0.1 :

9

Bonjour,

Avec la version 5.0.1, j arrive à installer le service sur la machine :slight_smile:

Mais malgre cela je n avais pas fait attention que mes modules sont des shelly gen1 donc non integrables dans gladys!!

J’ai découvert autre problème d’infrastructure sur mon Khadas VIM1S qui mérite d’être signalé, car il touche potentiellement toutes les intégrations externes en réseau bridge isolé, pas juste Shelly.

Le symptôme

Un conteneur d’intégration externe (réseau gladys-integrations, bridge isolé 172.30.0.0/24) ne peut atteindre aucun appareil du LAN — timeout systématique en sortie, alors que l’hôte lui-même contacte ces mêmes appareils sans problème.

La cause : mon kernel ne supporte aucun backend NAT

bash

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

En creusant :

  • nftables absent : CONFIG_NF_TABLES is not set dans le kernel
  • iptables-legacy absent aussi : le module ip_tables n’existe pas non plus (modprobe: FATAL: Module ip_tables not found)

Donc Docker ne peut créer aucune règle NAT/SNAT, quel que soit le backend — les conteneurs en bridge isolé ne peuvent jamais atteindre le LAN. C’est pour ça que "iptables": false était déjà configuré dans mon daemon.json (probablement pour permettre à Docker de démarrer du tout, faute de backend NAT fonctionnel) — mais ce contournement empêche justement le NAT dont les intégrations externes ont besoin.

Pourquoi ça touche potentiellement d’autres utilisateurs

C’est un kernel vendeur (Amlogic, très allégé, orienté Android TV box à l’origine) qui manque de plusieurs briques réseau/cgroup standards. Vu le nombre de SBC ARM « légers » utilisés dans la communauté domotique (TV box reconverties, mini-PC ARM bon marché…), ce n’est probablement pas un cas isolé.

Suggestion

Pour les intégrations externes qui doivent contacter des appareils du LAN (comme Shelly, Tasmota, etc. — tout ce qui n’est pas purement MQTT via l’hôte), serait-il possible de proposer une option de configuration en mode réseau host plutôt que bridge isolé ? Ça contournerait complètement le besoin de NAT pour les utilisateurs dont le système ne le supporte pas, moyennant l’avertissement habituel de sécurité (isolation réduite).

Je reste dispo pour tester si besoin.

10

Salut Didier !

Merci pour cette investigation, c’est super précis et ça aide beaucoup. :folded_hands:

Tu as mis le doigt sur la vraie cause : ton noyau est compilé sans netfilter (CONFIG_NF_TABLES is not set, pas d’iptables). Or c’est netfilter qui fait le NAT des réseaux bridge de Docker — sans lui, aucun conteneur en bridge ne peut atteindre le LAN, quelle que soit l’application. Ce n’est donc pas une limitation de Gladys : sur ce noyau, le réseau Docker est cassé en dessous de nos pieds (le script officiel check-config.sh de Docker flague d’ailleurs ces options comme requises).

Concernant le network=host, je préfère être transparent : ce ne sera pas une option dans Gladys. Tout le modèle de sécurité des intégrations externes repose sur l’isolation réseau : une intégration ne peut pas atteindre les services locaux de ta machine, ne peut pas parler aux autres intégrations, et la découverte réseau passe par un contrat explicite que tu approuves à l’installation. Avec le mode host, toutes ces garanties disparaissent — et « avec un avertissement » ne tient pas sur la durée : dès qu’une intégration populaire l’exige, l’avertissement devient un clic réflexe et la promesse « une intégration ne peut pas faire X » ne vaut plus rien. Détail qui a son importance : sans netfilter, l’isolation entre conteneurs (enable_icc=false) n’est de toute façon pas appliquée non plus — donc sur ce noyau, même sans mode host, on ne pourrait pas tenir nos garanties.

La bonne nouvelle : c’est réparable côté OS, et proprement. :tada:

  1. Vérifie d’abord si les modules existent mais ne sont pas chargés : sudo modprobe nf_tables puis ls /lib/modules/$(uname -r)/kernel/net/netfilter/. Vu ton CONFIG_NF_TABLES is not set, c’est peu probable, mais ça vaut 30 secondes.
  2. La solution que je te recommande : passer sur Armbian pour ton VIM1S. Il existe des images Armbian officielles et maintenues pour le Khadas VIM1S, avec un noyau qui inclut netfilter. Docker (bridge, NAT, isolation) fonctionne normalement dessus. Pense à faire une sauvegarde Gladys avant, tu restaureras sur la nouvelle installation.
  3. Alternativement, tu peux remonter le problème à Khadas : il y a déjà des tickets sur leur outil de build à ce sujet (fenix #297, fenix #68) — les modules netfilter manquants dans leurs noyaux vendor sont un problème connu chez eux.

Tiens-moi au courant si tu tentes Armbian, ton retour servira à tous ceux qui sont sur des SBC avec des noyaux vendor allégés ! :blush:

11

Bonsoir,

J ai migre sur armbian et reinstalle gladys, tout fonctionne correctement. J ai installe le support shelly et il a decouvert mon module shelly 2.5 gen1, j ai les infos remntees par le module mais je ne peux pas commander les relais avec l integration.

Merci pour l info sur armbian

Cordialement

Version installée:

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