Solucionar el error "Demasiados archivos abiertos" de Matrix Synapse en systemd

Matrix Synapse puede iniciarse con normalidad y luego dejar de aceptar conexiones, mostrar el mensaje "Demasiados archivos abiertos" o parecer bloqueado bajo carga. En una instalación de systemd, lo primero que hay que comprobar es el límite de descriptores de archivo heredado por el proceso Synapse en ejecución. Modificar el ulimitlímite de un shell o editar un archivo PAM generalmente no cambia el límite para un servicio que inicia systemd.

Los pasos que se describen a continuación se aplican a un host Linux donde Synapse se ejecuta como un servicio systemd. La unidad puede llamarse matrix-synapse.service, matrix-synapse@.service, o tener un nombre específico del paquete. Confirme la unidad real antes de copiar los comandos. Si Synapse se ejecuta en Docker, Kubernetes u otro contenedor, consulte la sección correspondiente más adelante.

¿Qué significa “Demasiados archivos abiertos”?

Linux asigna a cada proceso un límite de descriptores de archivo abiertos. Un descriptor puede referirse a un archivo, socket, tubería u otro recurso; por lo tanto, las conexiones de red también consumen descriptores. Cuando un proceso alcanza su límite flexible, un intento de abrir o aceptar otro descriptor puede fallar EMFILE. Linux también tiene un límite de tabla de archivos independiente para todo el sistema: el agotamiento de este límite puede producir errores ENFILE. Aumentar el límite de un servicio Synapse no solucionará una escasez en todo el sistema.

Las preguntas frecuentes oficiales de administración de Synapse indican que una alta actividad de conexión y federación puede consumir muchos descriptores de archivo, y que el agotamiento de estos puede provocar que el servidor deje de aceptar nuevas conexiones TCP. Su guía recomienda aumentar el límite a al menos 4096 en comparación con valores predeterminados anteriores como 1024 o 256. Considere esto como un límite mínimo para la resolución de problemas en la situación descrita, no como una recomendación de capacidad universal para todos los servidores domésticos. Comience por verificar el límite efectivo y el uso real.

La documentación de getrlimit y prlimit de Linux describe los límites flexibles y estrictos por proceso. Synapse también tiene una soft_file_limitconfiguración; la documentación de referencia de configuración de Synapse indica un valor predeterminado de cero, lo que le indica a Synapse que establezca su límite flexible al límite estricto que puede utilizar.

1. Confirme la unidad y diagnostique la falla.

Primero, encuentre el nombre real del servicio. En muchas instalaciones de paquetes es matrix-synapse.service, pero no asuma ese nombre si su instalación utiliza una unidad o trabajadores personalizados.

systemctl list-units --type=service --all | grep -i synapse
systemctl status matrix-synapse.service --no-pager
journalctl -u matrix-synapse.service --since "30 minutes ago" --no-pager

Busque el error exacto, la hora en que comenzó y si aparece durante un pico de tráfico, una actividad de federación o un reinicio. A continuación, inspeccione el límite que informa systemd actualmente:

systemctl show matrix-synapse.service -p LimitNOFILE -p MainPID

LimitNOFILEMuestra el límite configurado del administrador de servicios; no es un recuento de descriptores actualmente abiertos. Un comando de shell como este ulimit -nsolo informa el límite actual del shell y no es prueba del límite del servicio.

2. Aumentar el límite del servicio systemd con un drop-in

Utilice un paquete systemd drop-in para que las actualizaciones de paquetes no requieran editar el archivo de unidad del proveedor. El siguiente valor es un ejemplo, no garantiza la idoneidad para todos los servidores. Elija un límite que permita superar el pico de uso observado y compruebe la compatibilidad de la aplicación y las dependencias antes de establecer un valor inusualmente alto.

sudo systemctl edit matrix-synapse.service

Añade esto debajo del nuevo menú desplegable del editor:

[Service]
LimitNOFILE=65536

Guarda y sal, luego recarga systemd y reinicia Synapse durante una ventana de mantenimiento adecuada:

sudo systemctl daemon-reload
sudo systemctl restart matrix-synapse.service
systemctl show matrix-synapse.service -p LimitNOFILE

Un único LimitNOFILEvalor establece tanto el límite flexible como el límite estricto para el servicio en systemd. El manual de systemd también permite un soft:hardpar de valores. El límite flexible no puede exceder el límite estricto. Antes de elegir un valor muy alto, revise la documentación de systemd.exec , que indica problemas de compatibilidad para programas que utilizan la interfaz antigua select(2)con descriptores superiores a 1023. No asuma que todas las bibliotecas o complementos de su implementación admiten cualquier límite arbitrario.

3. Compruebe la configuración y los servicios de trabajo de Synapse.

Si la configuración de Synapse establece explícitamente soft_file_limitun valor bajo, la configuración de la aplicación puede mantener el límite flexible por debajo del límite máximo de systemd. Busque esa clave en los archivos de configuración activos y en la configuración incluida. Elimine cualquier anulación innecesaria o establézcala deliberadamente; el valor predeterminado documentado de cero le pide a Synapse que aumente su límite flexible al límite máximo disponible.

En una implementación multiproceso, cada trabajador es un proceso independiente y puede iniciarse mediante una unidad o plantilla independiente. Aumentar el límite del servicio principal no garantiza automáticamente que cada trabajador tenga el límite previsto. Inspeccione los nombres reales de las unidades de trabajador con systemctl list-units, luego aplique y verifique el complemento adecuado para cada servicio que lo necesite.

Asimismo, la configuración de /etc/security/limits.confla consola de inicio de sesión ulimitgeneralmente no rige un servicio del sistema iniciado directamente por systemd. Para esta configuración, cambie el límite de recursos de la unidad y verifíquelo en el proceso que systemd inició realmente.

4. Si Synapse se ejecuta en un contenedor

Una anulación de systemd a nivel de host para un servicio diferente no cambia automáticamente el límite de descriptores de archivo de un contenedor. Configure el entorno de ejecución del contenedor o la capa de orquestación. Para Docker Compose, la definición del servicio admite por contenedor ulimits; un ejemplo es:

services:
  synapse:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

El número es ilustrativo; ajústelo según el uso y los límites del host. La referencia del servicio Docker Compose documenta la ulimitsconfiguración. A partir de Docker Engine 29, las notas de la versión de Docker describen un cambio en el límite predeterminado de nofile asociado con containerd 2.1.5: los contenedores pueden recibir 1024 en lugar del valor predeterminado anterior de 1 048 576. Si el problema apareció después de una actualización de Engine, verifique el límite efectivo de contenedores y establezca explícitamente el ulimit necesario en la configuración de implementación. Consulte las notas de la versión de Docker Engine 29 y la referencia de docker run .

5. Verifique el límite en el proceso Synapse en ejecución.

Tras reiniciar, compruebe el límite a nivel de proceso, no solo la configuración de systemd. Obtenga el PID principal e inspeccione sus límites informados por el kernel:

PID=$(systemctl show --property=MainPID --value matrix-synapse.service)
grep "Max open files" "/proc/$PID/limits"
find "/proc/$PID/fd" -mindepth 1 -maxdepth 1 | wc -l

Si el PID principal es cero o pertenece a un proceso auxiliar en lugar de a Synapse, identifique el proceso Synapse en el cgroup del servicio e inspeccione ese PID. El recuento de descriptores es una instantánea; repítalo durante una carga representativa. Confirme que "Máx. archivos abiertos" refleja los límites flexibles y estrictos previstos, que el recuento se mantiene cómodamente por debajo del límite flexible y que el registro ya no informa del error.

Si el contador sigue aumentando hasta alcanzar el nuevo límite, es posible que este solo esté posponiendo el fallo. Las preguntas frecuentes de Synapse indican que las solicitudes lentas o bloqueadas pueden ser relevantes al investigar el agotamiento de descriptores de archivo. Revise los registros y el procesamiento de solicitudes, compare el número de descriptores a lo largo del tiempo e investigue una posible fuga o conexiones persistentes inesperadas, en lugar de seguir aumentando el límite indiscriminadamente.

Cuando aumentar el límite por servicio no es suficiente

Si los registros informan un error de agotamiento de la tabla de archivos en todo el sistema, como ENFILE, inspeccione el uso en todo el host y otros servicios; un LimitNOFILEcambio por servicio no aumentará la capacidad del kernel en todo el sistema. Evite cambiar los límites globales del kernel sin confirmar el error y comprender el impacto en todo el host. Si el límite informado del servicio permanece bajo después de una actualización, ejecute systemctl cat matrix-synapse.servicepara confirmar que la actualización se ha cargado, verifique el nombre de la unidad, recargue systemd y reinicie la unidad correcta.

Autocomprobación rápida

• ¿Has identificado la unidad o el contenedor exacto de Synapse que registra el error?
• ¿ systemctl showInforma sobre el límite previsto para esa unidad?
• ¿Muestra /proc/<Synapse-PID>/limitslos límites blandos y duros previstos después del reinicio?
• ¿El número de descriptores está por debajo del límite flexible bajo una carga máxima normal?
• ¿Se comprueban por separado las unidades de trabajo y la configuración de los contenedores cuando corresponda?
• ¿Se ha solucionado el problema o el uso sigue aumentando hasta alcanzar el nuevo límite máximo?

Si todas las comprobaciones a nivel de proceso se superan y el error se ha detenido durante un tráfico representativo, el cambio de límite de systemd está funcionando. Si los descriptores siguen acumulándose o el sistema informa de una escasez global, continúe investigando la causa en lugar de considerar un límite mayor como la solución definitiva.

Fuentes

• Preguntas frecuentes sobre la administración de Synapse: agotamiento de identificadores de archivo
• Referencia de configuración de Synapse: soft_file_limit
• Manual de systemd.exec: límites de recursos del servicio
• Manual de Linux: getrlimit y prlimit
• Notas de la versión 29 de Docker Engine