conmon v3: Podman ya prueba su monitor de contenedores escrito en Rust
Un contenedor en producción no se rompe casi nunca por el runtime. Se rompe por el proceso chiquito que está detrás, ese que se queda mirando el contenedor mientras nadie lo mira a él. En Podman ese proceso se llama conmon, y durante años fue un programa escrito en C de unas cinco mil líneas. Es justo el tipo de componente que nadie toca y de pronto aparece un CVE, o un hang raro, o un podman stop que deja el contenedor a medias.
Por eso me llegó la noticia de Fedora: el equipo de Podman y el de Quality armaron una test week entre el 12 y el 18 de octubre de 2026 para probar la versión 3 de conmon, reescrita en Rust. Yo la leí con la sensación de ser “otra test week”, pero al revisar los resultados publicados encontré algo más interesante que el anuncio mismo: la semana cerró con los casos en verde, con un solo desvío que se repitió en tres máquinas distintas. Eso es exactamente lo que uno quiere ver en un componente que va a estar en el camino crítico de tus servicios.
Este post es la guía práctica: qué cambió de verdad, cómo instalar el monitor nuevo en tu servidor, cómo probarlo sin romper nada y qué sigue pendiente para que esto deje de ser opcional.
TL;DR — Lo que vas a tener al final
- Tiempo de setup: 10 a 15 minutos. Instalar el paquete, escribir un drop-in de dos líneas y verificar con
podman info. - Requisitos: Fedora 43, 44 o 45 (también hay paquete en Rawhide), un runtime OCI instalado (crun o runc) y una máquina de pruebas. En RHEL, Debian, Ubuntu y openSUSE todavía no existe el paquete.
- Resultado: Podman arranca contenedores nuevos con conmon v3, el monitor escrito en Rust. Los que ya estaban corriendo siguen con el monitor viejo, sin tocar.
- Troubleshooting: si un contenedor no levanta, revisa dos cosas: que el binario sea exactamente
/usr/bin/conmon-v3y que el contenedor sea nuevo. Y sipodman stoptermina en SIGKILL, no es tu error: es el único desvío que reportó la test week.
Qué hace conmon y por qué importa aunque no toques Podman
Vale la pena separar las piezas porque aquí es donde se confunden los roles. Cuando ejecutas podman run, pasan tres cosas distintas:
- Un runtime OCI (crun o runc) crea el contenedor y se convierte en su proceso principal.
- Un init de PID 1 opcional (catatonit en las distribuciones que lo empaquetan) puede encargarse de reaping de zombies y señalización.
- conmon es el monitor: se queda pegado al contenedor, mantiene abierto el socket de
podman attach, reenvía la entrada y salida estándar, escribe los logs a disco o al journal de systemd y, cuando el contenedor muere, graba la hora y el código de salida.
Es decir: conmon es el puente entre el gestor de contenedores y el runtime, y es el componente que sobrevive al comando que lo lanzó. Cuando podman run termina, el contenedor sigue vivo y conmon sigue ahí, sosteniendo los logs y el exit status.
Por eso un bug ahí no se ve como “un contenedor raro”. Se ve como logs que se truncan, un attach que se cuelga, un exit status que no cuadra con lo que dijo la shell, o un servicio que systemd no puede parar limpiamente. Y es un proceso que corre las 24 horas en cada contenedor que tienes en pie.
Qué cambia en la versión 3 escrita en Rust
El anuncio de Fedora Magazine resume el cambio como “evitar errores de memoria comunes en código no seguro”. Conviene atender a la cita literal: el texto publicado dice “common memory errors in safe code”, con safe donde debería decir unsafe. Es una errata del anuncio, y el diseño upstream confirma que el beneficio de memoria de Rust es real pero secundario. Pero el documento de diseño del proyecto en upstream es más honesto y enumera los motivos en otro orden:
- Sistema de logs basado en plugins. Es el motivo principal. El backend de logging deja de estar acoplado al núcleo y cada backend (archivo, journald, syslog) implementa la misma interfaz, lo que hace que extenderlos y probarlos sea mucho más barato.
- Arquitectura nueva para el manejo de errores. En la versión 2 hay casos en los que conmon simplemente sale sin propagar el error a Podman, y el usuario se queda sin ninguna información de por qué falló el arranque del contenedor.
- Código más mantenible. Y aquí está el punto que casi nadie menciona: el documento de diseño habla de una “barrera de lenguaje”. Muy pocos mantenedores del ecosistema de contenedores tienen experiencia profunda en C, y el proyecto lleva años sin gente nueva que pueda tocar esa base de código con confianza.
- Seguridad de memoria. Es un beneficio real y un objetivo declarado, pero el propio diseño lo pone como beneficio secundario, no como la razón principal.
Un detalle que se escapa: el diseño upstream estima que conmon v3 se puede mantener en 1.2 a 1.5 MB de memoria por contenedor, contra los 600 KB que el propio equipo atribuye a la versión 2. Ojo con la palabra: es una estimación de diseño, no una medición publicada. Sigue siendo un proceso diminuto para lo que hace, pero no es gratis. Si vas a correr cientos de contenedores por nodo, ese es el número que de verdad te importa, más que cualquier argumento sobre el lenguaje en que está escrito.
El estado de las versiones, sin adornos
| Componente | Última versión upstream | Fecha | Dónde está |
|---|---|---|---|
| conmon v2 (C) | v2.2.1 | 12-feb-2026 | Default en Fedora, RHEL 10, CentOS Stream 10, Debian, Ubuntu (universe) y openSUSE |
| conmon v3 (Rust) | Solo v3.0.0-dev |
10-jul-2026 (único tag) | Paquete aparte en Fedora 43/44/45 y Rawhide |
Ojo con el número de versión que vas a ver en Fedora: el paquete se llama 3.0.0~dev-5.20261007092403828293 o similar. El 3.0.0 viene del Cargo.toml del proyecto y el -dev significa exactamente lo que dice: no hay release estable de conmon v3. El único tag upstream es v3.0.0-dev, del 10 de julio de 2026. Si alguien te dice que “conmon 3.0.0 ya salió”, te está leyendo el número de versión interno, no un anuncio de release.
Instalar conmon v3 en Fedora
El paquete ya está en los repos oficiales de Fedora, no hace falta ningún COPR ni repositorio de pruebas para el caso general. El comando es el que esperarías:
sudo dnf install conmon-v3
rpm -q conmon-v3
podman --version
El primer comando instala el binario en /usr/bin/conmon-v3 sin tocar el conmon v2 que ya tienes. El segundo te muestra el RPM exacto, que es donde se ve el ~dev. El tercero confirma que Podman sigue en pie.
Si prefieres el paquete desde el COPR de los mantenedores —que es lo que todavía recomienda el README del proyecto, aunque está desactualizado respecto a Fedora oficial—, el orden importa porque el COPR trae Podman sin liberar:
sudo dnf copr enable rhcontainerbot/podman-next
sudo dnf install conmon-v3
sudo dnf copr disable rhcontainerbot/podman-next
El copr disable del final no es opcional. Si dejas el repositorio activo, el próximo dnf update te va a instalar versiones sin liberar de Podman y de otras herramientas, y el problema aparece semanas después, cuando ya no recuerdas por qué cambió algo.
Activar conmon v3 con un drop-in de containers.conf
El mecanismo es el estándar de Podman: un archivo de configuración en formato containers.conf dentro de un directorio de drop-ins. Los archivos se leen en orden alfabético, por eso el 99- del nombre: tu drop-in gana sobre cualquier valor anterior.
sudo install -d -m 755 /etc/containers/containers.conf.d
echo '[engine]' | sudo tee /etc/containers/containers.conf.d/99-conmon-v3.conf
echo 'conmon_path = ["/usr/bin/conmon-v3"]' | sudo tee -a /etc/containers/containers.conf.d/99-conmon-v3.conf
cat /etc/containers/containers.conf.d/99-conmon-v3.conf
El tee -a del segundo comando es el que anexa, y por eso va con guion: sin él, sobrescribirías la línea anterior y te quedaría un archivo con solo la segunda línea, sin el encabezado [engine]. Un archivo de containers.conf sin la sección correcta no da error, simplemente se ignora, y vas a perder horas intentando a adivinar por qué Podman sigue con el monitor viejo.
El cat final es tu confirmación de que el archivo quedó como debe. Si ves las dos líneas, hay un problema más adelante. Si ves solo una, el problema está aquí.
El detalle que casi nadie menciona
Este drop-in es de sistema. Tu usuario puede sobreescribirlo con su propia configuración en ~/.config/containers/containers.conf. Si tienes usuarios rootless, el archivo del usuario gana sobre el del sistema y tu podman info como root va a decir una cosa mientras el de tu usuario dice otra. Por eso el paso siguiente chequea los dos.
Verificar que Podman está usando conmon v3
La verificación es un podman info y mirar la sección conmon. Si el path apunta a /usr/bin/conmon-v3 y la versión empieza con 3, estás dentro.
podman info | grep -i conmon
sudo podman info | grep -i conmon
podman info --format '{{.Host.OCIRuntime.Name}}'
Las dos primeras líneas te dan path y versión. La tercera es un control extra: te dice qué runtime OCI estás usando, que es una variable distinta del monitor y que conviene tener clara cuando midas los tiempos de los reportes.
Lo que deberías ver en la salida es algo equivalente a esto:
conmon:
package: conmon-v3-3.0.0~dev-5.20261007092403828293.main.69.g3f6f404.fc43
path: /usr/bin/conmon-v3
version: 'conmon version 3.0.0-dev, commit: 3f6f404'
Si el path sigue diciendo /usr/bin/conmon, el drop-in no se está leyendo. Revisa el nombre del archivo, que el orden alfabético importa, y revisa que estés en la máquina correcta.
Probar el comportamiento real: attach, exec y logs
Un monitor de contenedores no se prueba con un podman run y un docker ps. Lo que importa es el comportamiento en los bordes, que es justo lo que pidió el equipo de Podman para la test week. Esta es una lista de trabajo para tu máquina de pruebas:
podman run -d --name prueba-conmon docker.io/library/alpine:latest sleep 300
podman exec -it prueba-conmon sh
podman logs prueba-conmon
podman logs --timestamps prueba-conmon
El primer comando arranca un contenedor de fondo. El segundo entra en modo interactivo: es el caso que más ha dado problemas, porque exige que conmon reenvíe la entrada y la salida correctamente sobre una PTY. El tercero y el cuarto leen los logs: mira sobre todo las líneas largas y las que no terminan en salto de línea, porque ahí es donde el buffer se comporta distinto entre versiones.
Si quieres comparar lado a lado en el mismo host, el flag --conmon de Podman te deja forzar el binario solo para una invocación, sin tocar ningún archivo de configuración:
podman --conmon /usr/bin/conmon-v3 run --rm docker.io/library/alpine:latest sh -c 'echo prueba; sleep 2'
Ese es el modo más seguro para una primera exploración: nada de archivos, nada de estado global, y al terminar el contenedor desaparece.
Ejecutar servicios declarativos con Quadlet
Si administras contenedores como servicios, no los estás corriendo con podman run sino con Quadlet, el generador de units de systemd. Y ahí hay una relación de dependencia fuerte: la relación uno a uno entre conmon y el contenedor es obligatoria justamente porque systemd y Quadlet asumen que hay exactamente un monitor por contenedor.
El flujo de prueba completo con Quadlet es este:
mkdir -p "$HOME/.config/containers/systemd"
echo '[Container]' > "$HOME/.config/containers/systemd/prueba.container"
echo 'Image=registry.access.redhat.com/ubi9/ubi' >> "$HOME/.config/containers/systemd/prueba.container"
echo 'Exec=sh -c "while true; do sleep 5; done"' >> "$HOME/.config/containers/systemd/prueba.container"
systemctl --user daemon-reload
systemctl --user start prueba.service
systemctl --user status prueba.service
journalctl --user -u prueba.service -n 50 --no-pager
El daemon-reload es indispensable: Quadlet es un generador, no un parser. systemd corre el generador en cada reload y convierte el archivo .container en un .service real. Si te saltas ese paso, systemctl --user start va a decir que no encuentra la unidad aunque el archivo exista.
Si necesitas las units de root en vez de las de tu usuario, los archivos van en /etc/containers/systemd/ y el daemon-reload es de sistema, con sudo.
Diagnosticar el desvío de SIGKILL al detener un contenedor
Este es el hallazgo concreto de la test week. Tres participantes, en tres máquinas distintas, reportaron lo mismo: podman stop con un timeout corto termina resorting a SIGKILL. El mensaje que aparece en el terminal es explícito: StopSignal SIGTERM failed to stop container, resorting to SIGKILL. Los comandos para confirmarlo son estos:
podman stop -t 2 prueba-conmon
podman inspect prueba-conmon --format '{{.State.ExitCode}}'
podman inspect prueba-conmon --format '{{.State.OOMKilled}}'
El ExitCode te dice con qué código terminó realmente el contenedor. El OOMKilled te dice si fue el kernel por falta de memoria, que es un diagnóstico completamente distinto: si el proceso murió por OOM el problema es de límites, y si no, es que conmon no logró detenerlo limpiamente en el tiempo dado.
El contexto técnico: el repositorio de conmon v3 tiene mergeado un cambio que preserva el exit status cuando systemd manda SIGTERM al contenedor, y varios otros parches apuntados a evitar cuelgues del console socket. Ninguno de esos cambios elimina el desvío del SIGKILL: lo que hacen es que el exit status que ves después de un stop forzado sea el correcto. La zona de terminación sigue siendo la más frágil del componente en este momento. No es un problema que afecte a tus contenedores en producción, pero sí es la zona donde yo miraría primero si reportas un bug.
Revertir el cambio cuando termines la prueba
La reversión es borrar un archivo. Eso es lo mejor de usar drop-ins en lugar de editar /usr/share/containers/containers.conf a mano: no hay estado residual en ningún otro lado.
sudo rm -f /etc/containers/containers.conf.d/99-conmon-v3.conf
podman info | grep -i conmon
Y vuelve a ser exactamente como antes: los contenedores nuevos usan el monitor anterior y los que ya estaban corriendo nunca cambiaron de monitor en primer lugar. El único que se queda con conmon v3 es el que habías arrancado con el drop-in activo, y ese hay que recrearlo para volver a v2.
Si prefieres no tocar el sistema, hay una variante aún más limpia: quita el drop-in del sistema y déjalo solo en la configuración del usuario, con un archivo propio. El orden de precedencia hace que puedes tener conmon v3 para tus pruebas de usuario y v2 para todo lo demás en la misma máquina.
Por qué conmon v3 todavía no es el default en ninguna distro
Porque todavía no hay release estable. Así de simple. Revisando los repositorios: Fedora mantiene /usr/bin/conmon (v2, versión 2.2.1) como valor por defecto de engine.conmon_path, y el paquete de v3 vive aparte. En RHEL 10 y CentOS Stream 10 solo está conmon 2.2.1. En Debian sid está la 2.1.13, en openSUSE Tumbleweed la 2.2.1, y en Ubuntu la 2.1.13, aunque esa vive en universe y no en main.
El plan original de upstream era integrar conmon v3 en Podman 6.0, en la primavera de 2026. No ocurrió: Podman 6.0.0 salió el 24 de junio de 2026 y sus notas de release no mencionan conmon v3. Tampoco la 6.1.4, del 12 de octubre. El documento de diseño sigue en el repositorio de Podman, y eso es justamente lo que indica que la feature no está cerrada.
Lo que sí pasó, y es la señal más clara de que la migración arrancó, fue durante la propia test week: el 15 de octubre se mergeó en Podman el PR que hace que la integración continua del proyecto en Fedora Rawhide use conmon v3 por defecto. Eso no cambia nada para tu servidor, pero significa que los jobs de integración continua en Fedora Rawhide ya se ejecutan contra el monitor nuevo. Cuando el default se mueva, no lo hicieron en la oscuridad.
Un detalle histórico que vale la pena conocer: hubo un intento anterior de reescribir conmon en Rust, llamado Conmon-rs, llevado por los mantenedores de CRI-O. Está abandonado, y el documento de diseño explica por qué: la complejidad de la integración con gRPC, el consumo de recursos y la incompatibilidad uno a uno con Quadlet. Y hay una dirección más radical sobre la mesa para el futuro: eliminar conmon por completo y delegar esa función en systemd. Ese debate sigue abierto.
Mi lectura: para quién tiene sentido hoy
Si tienes Podman en producción y no estás moviendo contenedores en un ambiente hostil, yo me quedaría en v2 por ahora. No porque v3 sea peor, sino porque v3 todavía es un -dev que no ha pasado por un ciclo de release completo, y porque el cambio de monitor es de esos que no producen un error visible cuando algo sale mal: producen logs truncados y servicios que no paran limpio.
Lo que sí tiene sentido hoy es probarlo. Y la mejor noticia es que el costo de la prueba es bajísimo: un paquete, un drop-in de dos líneas y un rm para revertir. Si tienes una máquina de pruebas, un homelab o un nodo que no carga producción, el tiempo que te toma es el que tardas en copiar y pegar cuatro comandos.
Y para los que mantienen Fedora o hacen contribuciones upstream, hay una noticia más valiosa que la del anuncio: la test week cerró con 13 participantes distintos, sobre Fedora 43, 44, 45 y Rawhide, con todos los casos en verde y un único desvío recurrente ya identificado. Eso es exactamente el tipo de señal que hace que una feature se acerque al default. Mi apuesta es que conmon v3 va a ser el default de Podman en la próxima mayor versión, y que el momento de adoptarlo en tu nodo será cuando el RPM deje de llevar ~dev en el número de versión.
Cuando llegue ese día, vas a tener dos rutas: cambiar el drop-in y ya, o esperar a que tu distro lo empaquete como default y no tocar nada. La segunda es la que va a llegar sola.
Preguntas frecuentes
¿Qué pasa con los contenedores que ya están corriendo si activo conmon v3?
No se les toca nada. El monitor se elige en el momento en que se crea el contenedor, así que los que ya están en ejecución siguen usando conmon v2 aunque cambies el drop-in. Solo los contenedores que arranques después del cambio usarán conmon v3. Para que uno existente vuelva a v2 tendrías que recrearlo.
¿Conmon v3 ya es el default en Fedora, RHEL, Debian u openSUSE?
No, en ninguno. Fedora, RHEL 10, CentOS Stream 10, Debian, Ubuntu y openSUSE mantienen conmon v2 como default; el paquete conmon-v3 solo existe en Fedora 43, 44, 45 y Rawhide. upstream tampoco ha integrado el monitor nuevo en ninguna release estable de Podman, así que activarlo es siempre una decisión manual.
¿Puedo probar conmon v3 sin tocar la configuración global?
Sí. El flag –conmon de Podman te permite forzar el binario solo para una invocación: podman –conmon /usr/bin/conmon-v3 run. No escribe ningún archivo, no cambia el estado global y el contenedor se borra al terminar. Es la forma más segura de ver el comportamiento nuevo sin tocar nada del sistema.
¿Qué hago si podman stop termina con SIGKILL en vez de parar limpio?
Primero descarta que sea falta de memoria: podman inspect con el campo State.OOMKilled te lo dice. Si es falso, es el desvío que reportaron tres participantes de la test week, ligado a la ruta de terminación con SIGTERM que systemd usa. Suele aparecer con timeouts cortos como podman stop -t 2, y conviene subir el timeout antes de culpar al monitor.
¿Qué diferencia real voy a notar entre conmon v2 y v3 en mi día a día?
Casi ninguna en el uso normal: la interfaz con Podman es la misma. Los cambios se notan en la práctica: logs más consistentes con líneas largas o sin salto de línea final, un attach interactivo más estable y exit status más confiables. Lo que no vas a notar todavía es el rendimiento, porque v3 sigue en versión de desarrollo.
