Integraciones externas no disponibles en SBC ARM sin soporte CONFIG_CFS_BANDWIDTH (Khadas, potencialmente Raspberry Pi)

Hola,

Estoy reportando un problema bloqueador para cualquier integración externa en mi Khadas VIM1S (Ubuntu 24.04, kernel Amlogic 7.0.0+).

Síntoma — imposible iniciar una integración externa (probado con Shelly), error en los registros:

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

Causa aislada, reproducible fuera de Gladys:

bash

docker run --rm hello-world              # OK
docker run --rm --cpus="1.0" hello-world # falla con el mismo error

Confirmación del kernel :

bash

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

Esta bandera de compilación del kernel proporciona cpu.max (cuota de CPU cgroup v2). Sin ella, ningún límite --cpus puede ser aplicado a un contenedor — por lo tanto, tan pronto como las integraciones externas aplican este límite en la creación, falla sistemáticamente, sin posibilidad de contornear desde la configuración del sistema (probado: controlador cgroup systemd y cgroupfs, delegación cgroup verificada correcta en todos los niveles).

Alcance potencial: esto no está aislado a mi hardware. La Raspberry Pi ha tenido históricamente el mismo problema (ticket raspberrypi/linux#3387, aún abierto).

Sugerencia: hacer que el límite de CPU sea opcional, o cambiar a --cpu-shares (ponderación, no requiere cpu.max) en lugar de una cuota estricta — o detectar la ausencia de cpu.max y crear el contenedor sin límite en lugar de fallar.

Estoy disponible para probar en este hardware si es necesario. Gracias

¡Bienvenido al foro @Didier_Hilary!

¿No se parece tu problema al que tuvimos con los Synology?

Si es así, convertiremos tu publicación en una solicitud de función para tener en cuenta otras máquinas.

Buenas noches,

El problema no parece ser exactamente el mismo, el siguiente comando da la sintaxis correcta si entiendo bien el problema de Synology!!

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

Quizás el problema viene de mi sistema, no gestiona bien las cuotas!!

¿Hay alguna manera de desactivar este mecanismo de cuotas a nivel de las integraciones de Gladys?
Gracias

Atentamente

@pierre-gilles ¿ya has visto este problema antes?

He lanzado Fable en él

¡Hola a todos!

Este tema está ahora en desarrollo.

Se ha abierto una PR para comenzar las integraciones externas en los kernels sin soporte de ancho de banda CFS:

No dudes en seguir la PR, probar (opcional, especialmente para pequeñas solicitudes) y dar tus comentarios aquí si es necesario.

Hola @Didier_Hilary,

Te propongo un build para arm64 para probar este parche:

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

Puedes probar, por ejemplo, con este comando (ten en cuenta los volúmenes de Docker, el puerto, asegúrate de modificar este comando según tu instalación):

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

También he implementado el parche en la 5.0.1:

Hola,

Con la versión 5.0.1, logré instalar el servicio en la máquina :slight_smile:

Pero, a pesar de eso, no me di cuenta de que mis módulos son Shelly Gen1, por lo que no son integrables en Gladys!!

Descubrí otro problema de infraestructura en mi Khadas VIM1S que merece ser reportado, ya que afecta potencialmente todas las integraciones externas en red bridge aislada, no solo Shelly.

El síntoma

Un contenedor de integración externa (red gladys-integrations, bridge aislado 172.30.0.0/24) no puede alcanzar ningún dispositivo de la LAN — tiempo de espera sistemático al salir, mientras que el host mismo contacta estos mismos dispositivos sin problema.

La causa: mi kernel no soporta ningún backend NAT

bash

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

Al investigar:

  • nftables ausente: CONFIG_NF_TABLES is not set en el kernel
  • iptables-legacy también ausente: el módulo ip_tables tampoco existe (modprobe: FATAL: Module ip_tables not found)

Por lo tanto, Docker no puede crear ninguna regla NAT/SNAT, sin importar el backend — los contenedores en bridge aislado nunca pueden alcanzar la LAN. Por eso "iptables": false ya estaba configurado en mi daemon.json (probablemente para permitir que Docker se inicie, por falta de un backend NAT funcional) — pero este contorno impide exactamente el NAT que las integraciones externas necesitan.

Por qué esto potencialmente afecta a otros usuarios

Es un kernel de vendedor (Amlogic, muy ligero, orientado a cajas de Android TV en origen) que carece de varios componentes estándar de red/cgroup. Dado el número de SBC ARM « ligeros » utilizados en la comunidad de domótica (cajas de TV reconvertidas, mini-PC ARM económicos…), probablemente no sea un caso aislado.

Sugerencia

Para las integraciones externas que deben contactar dispositivos de la LAN (como Shelly, Tasmota, etc. — todo lo que no es puramente MQTT a través del host), ¿sería posible ofrecer una opción de configuración en modo de red host en lugar de bridge aislado? Esto evitaría completamente la necesidad de NAT para los usuarios cuyo sistema no lo soporta, con la advertencia habitual de seguridad (aislamiento reducido).

Estoy disponible para probar si es necesario.

¡Hola Didier!

Gracias por esta investigación, es muy precisa y ayuda mucho. :folded_hands:

Has dado en el clavo con la verdadera causa: tu núcleo está compilado sin netfilter (CONFIG_NF_TABLES is not set, sin iptables). Es netfilter el que hace el NAT de las redes puente de Docker — sin él, ningún contenedor en puente puede alcanzar la LAN, sin importar la aplicación. Por lo tanto, no es una limitación de Gladys: en este núcleo, la red de Docker está rota bajo nuestros pies (el script oficial check-config.sh de Docker marca de hecho estas opciones como requeridas).

Respecto a network=host, prefiero ser transparente: no será una opción en Gladys. Todo el modelo de seguridad de las integraciones externas se basa en el aislamiento de red: una integración no puede alcanzar los servicios locales de tu máquina, no puede comunicarse con otras integraciones, y el descubrimiento de red pasa por un contrato explícito que apruebas en la instalación. Con el modo host, todas estas garantías desaparecen — y « con una advertencia » no dura en el tiempo: tan pronto como una integración popular lo exija, la advertencia se convierte en un clic reflejo y la promesa « una integración no puede hacer X » no vale nada. Detalle que tiene su importancia: sin netfilter, el aislamiento entre contenedores (enable_icc=false) tampoco se aplica — por lo tanto, en este núcleo, incluso sin modo host, no podríamos mantener nuestras garantías.

La buena noticia: es reparable desde el lado del SO, y de manera limpia. :tada:

  1. Primero, verifica si los módulos existen pero no están cargados: sudo modprobe nf_tables luego ls /lib/modules/$(uname -r)/kernel/net/netfilter/. Dado tu CONFIG_NF_TABLES is not set, es poco probable, pero vale 30 segundos.
  2. La solución que te recomiendo: cambiar a Armbian para tu VIM1S. Existen imágenes oficiales y mantenidas de Armbian para el Khadas VIM1S, con un núcleo que incluye netfilter. Docker (puente, NAT, aislamiento) funciona normalmente en ellas. No olvides hacer una copia de seguridad de Gladys antes, la restaurarás en la nueva instalación.
  3. Alternativamente, puedes reportar el problema a Khadas: ya hay tickets sobre su herramienta de compilación al respecto (fenix #297, fenix #68) — los módulos netfilter faltantes en sus núcleos de proveedor son un problema conocido para ellos.

Manténme informado si intentas con Armbian, tu retroalimentación será útil para todos aquellos que están en SBC con núcleos de proveedor reducidos. :blush:

Buenas noches,

He migrado a Armbian y he reinstalado Gladys, todo funciona correctamente. He instalado el soporte Shelly y ha detectado mi módulo Shelly 2.5 Gen1, tengo la información remitida por el módulo pero no puedo controlar los relés con la integración.

Gracias por la información sobre Armbian

Cordialmente

Versión instalada:

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