Dockhand falla al actualizar contenedores gestionados por Quadlet

Un usuario ha descrito en r/selfhosted un fallo reproducible en el flujo de actualización de Dockhand: cuando los contenedores están desplegados como unidades Quadlet de systemd, la herramienta se atasca siempre en el mismo paso, el renombrado del contenedor antiguo. El error literal es "Failed to rename old container" y le ha ocurrido igual en tres contenedores distintos dentro de la misma tanda de actualización, con imágenes y aplicaciones diferentes.

El montaje es el habitual en quien autohospeda sin privilegios: Podman rootless sobre Debian 13, los contenedores declarados en ~/.config/containers/systemd/*.container y todas las unidades con Restart=always. Dockhand se conecta al host a través del socket rootless de Podman para gestionar y actualizar contenedores en un par de máquinas.

La secuencia que se rompe

El flujo de Dockhand es pull de la imagen nueva, parada del contenedor antiguo, renombrado de ese contenedor, creación y arranque del nuevo y borrado del viejo. El fallo llega justo después de parar el contenedor, cuando toca renombrarlo.

La explicación que da el autor del hilo encaja con lo que hace systemd. Al parar el contenedor vía API, systemd ve que el proceso muere y, por el Restart=always de la unidad, lo levanta otra vez de inmediato, recreando un contenedor con el mismo nombre original antes de que Dockhand pueda renombrarlo. La herramienta intenta entonces renombrar lo que cree que sigue siendo el contenedor parado, pero el hueco del nombre ya lo ha vuelto a ocupar la instancia que systemd acaba de resucitar. De ahí el fallo.

En la práctica es una carrera entre dos cosas que quieren gestionar el ciclo de vida del mismo contenedor por su cuenta: systemd y Quadlet por un lado, las llamadas directas a la API de Podman que hace Dockhand por otro. Ninguno de los dos sabe que el otro está ahí.

Qué se puede hacer

El propio autor plantea si existe una forma de que una herramienta de actualización sea "consciente de Quadlet": detectar la etiqueta PODMAN_SYSTEMD_UNIT y, en lugar de hacer el stop, rename y recreate contra la API, delegar en systemctl --user restart. Es la vía limpia, porque deja que systemd haga lo que ya sabe hacer y evita la pelea por el nombre.

Mientras eso no exista, la salida práctica que él mismo usa es saltarse el auto-update de Dockhand sobre contenedores gestionados por Quadlet y hacer el ciclo a mano: podman pull seguido de systemctl restart.

Conviene tomarlo como lo que es: el reporte de un usuario, con su diagnóstico y sin confirmación por parte del proyecto. No hay respuesta del equipo de Dockhand en el hilo, así que la teoría de la carrera es razonable pero no verificada.

El caso importa más allá de esta herramienta. Cualquier utilidad que actualice contenedores contra la API de Podman chocará con lo mismo si el contenedor vive dentro de una unidad de systemd con reinicio automático: son dos planos de control, el declarativo y el imperativo, y hay que elegir quién manda antes de automatizar nada.