Problema

En varios despliegues de Proxmox VE el terminal integrado (Shell) deja de responder después de unos minutos de inactividad o de ejecución de comandos ligeros. El síntoma típico es una pantalla estática que no acepta entrada, obligando al usuario a cerrar la pestaña del Shell y volver a abrirla. Al mismo tiempo, operaciones que requieren apt/dpkg (actualizaciones, instalación de paquetes, uso del botón Upgrade en la UI) fallan con errores como:

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33069 (apt)

El bloqueo persiste incluso después de cerrar la sesión SSH, y journalctl -f no muestra mensajes relevantes. El problema afecta tanto al acceso web (Shell tab) como a conexiones SSH, lo que impide la gestión rutinaria del nodo.

Causa

El congelamiento del Shell y los bloqueos de apt suelen derivar de una combinación de factores que comparten un denominador común: un proceso apt/dpkg que queda colgado y mantiene el lock de la base de datos de paquetes. Las causas más frecuentes son:

  1. Actualización interrumpida – Cuando la UI de Proxmox lanza apt-get dist-upgrade y la sesión se corta (p.ej., por timeout del navegador o pérdida de red), el proceso hijo sigue ejecutándose en segundo plano. El lock se mantiene activo y el Shell pierde la capacidad de crear nuevas sesiones porque systemd intenta abrir un pseudo‑tty bajo un entorno que ya está bloqueado.

  2. Timeout del watchdog del Shell – El terminal web de Proxmox está respaldado por pveproxy y pve-manager. Si el proceso pveproxy detecta inactividad prolongada, cierra la conexión del WebSocket. La sesión de shell queda “zombificada” y el proceso bash sigue vivo sin salida, consumiendo recursos y, en algunos casos, iniciando una transacción apt implícita (por ejemplo, al ejecutar apt-get update antes de que el usuario lo vea).

  3. Conflicto entre apt-daily y apt-daily-upgrade – En versiones recientes de Debian/Proxmox, los timers de systemd (apt-daily.timer y apt-daily-upgrade.timer) pueden iniciar una actualización automática justo cuando el administrador abre el Shell. Si la actualización se ejecuta en segundo plano mientras el usuario intenta usar apt manualmente, ambos procesos compiten por el mismo lock.

  4. Problemas de I/O en el almacenamiento – En entornos LXC o ZFS con alta latencia, la escritura del lock file puede tardar más de lo esperado, provocando que el proceso que lo creó no libere el lock al terminar. El Shell parece congelado porque el kernel está esperando que el lock se libere antes de lanzar una nueva sesión.

Solución

La estrategia consiste en identificar y eliminar el proceso que mantiene el lock, y prevenir que vuelva a aparecer inesperadamente. Se pueden aplicar tres enfoques que cubren la mayoría de los escenarios:

1. Liberar el lock manualmente

  1. Localizar el PID que posee el lock: 
    fuser -v /var/lib/dpkg/lock-frontend
  2. Verificar que el proceso sea realmente apt/dpkg y no una tarea crítica (por ejemplo, una actualización del kernel en curso). Si está colgado, terminarlo: 
    kill -9 <PID>
  3. Eliminar los archivos de lock residuales: 
    rm -f /var/lib/dpkg/lock-frontend /var/cache/apt/archives/lock
  4. Reconfigurar dpkg para asegurar la consistencia: 
    dpkg --configure -a

2. Desactivar los timers automáticos durante la ventana de mantenimiento

Si la interferencia proviene de apt-daily o apt-daily-upgrade, desactivar temporalmente los timers evita que el sistema intente una actualización simultánea:

systemctl stop apt-daily.timer apt-daily-upgrade.timer
systemctl disable apt-daily.timer apt-daily-upgrade.timer

Una vez completada la tarea manual (actualización vía UI o línea de comandos), volver a habilitarlos:

systemctl enable apt-daily.timer apt-daily-upgrade.timer
systemctl start apt-daily.timer apt-daily-upgrade.timer

3. Configurar el Shell de Proxmox para que no se cierre por timeout

El componente que controla la sesión web es pveproxy. Ajustar su tiempo de espera evita que el WebSocket se cierre inesperadamente:

  1. Editar /etc/pve/datacenter.cfg y añadir (o modificar) la línea:

    shell_timeout = 0

    0 desactiva el timeout; también se puede usar un valor alto en segundos (p.ej., 3600).

  2. Reiniciar el proxy:

    systemctl restart pveproxy

Con el timeout desactivado, la pestaña del Shell permanece viva mientras el proceso apt termina, evitando la necesidad de cerrar y volver a abrir la sesión.

4. Opcional: usar un terminal externo

Para operaciones críticas (actualizaciones mayores, migraciones), abrir una sesión SSH directa al nodo y ejecutar los comandos allí elimina la capa de WebSocket y reduce la probabilidad de desconexiones inesperadas. Si el lock persiste, sigue los pasos de la sección 1.

Cuándo aplicar esta solución

  • Síntomas de congelamiento del Shell acompañados de errores de lock en /var/lib/dpkg/lock-frontend.
  • Actualizaciones fallidas tanto desde la UI como desde la línea de comandos.
  • Timers apt activos durante ventanas de mantenimiento programadas.
  • Entornos con alta latencia de almacenamiento donde los locks pueden quedar colgados.
  • No aplicar si el proceso que posee el lock está ejecutando una actualización del kernel o una migración de VM en curso; en ese caso, esperar a que finalice.

Código

# 1. Detectar proceso que mantiene el lock
fuser -v /var/lib/dpkg/lock-frontend

# 2. Terminar proceso colgado (reemplazar <PID>)
kill -9 <PID>

# 3. Eliminar archivos de lock
rm -f /var/lib/dpkg/lock-frontend /var/cache/apt/archives/lock

# 4. Reconfigurar dpkg
dpkg --configure -a

# 5. Desactivar timers apt (mantenimiento)
systemctl stop apt-daily.timer apt-daily-upgrade.timer
systemctl disable apt-daily.timer apt-daily-upgrade.timer

# 6. Ajustar timeout del Shell de Proxmox
echo "shell_timeout = 0" >> /etc/pve/datacenter.cfg
systemctl restart pveproxy

Verificación

  1. Comprobar ausencia de lock:

    ls -l /var/lib/dpkg/lock-frontend /var/cache/apt/archives/lock

    Ambos archivos no deben existir.

  2. Ejecutar una actualización de prueba:

    apt-get update && apt-get upgrade -y

    La salida debe completarse sin mensajes de “Could not get lock”.

  3. Abrir el Shell en la UI y dejarlo abierto 10 minutos. Verificar que sigue aceptando comandos.

  4. Reactivar timers y observar que, después de la ventana de mantenimiento, systemctl status apt-daily.timer muestra “active (waiting)”.

Notas adicionales

  • En clústeres con varios nodos, asegúrate de que el lock no provenga de una operación distribuida (por ejemplo, pvecm updatecerts). En esos casos, la solución debe aplicarse en el nodo que realmente ejecuta apt.
  • Si usas ZFS, revisa que el pool no tenga errores (zpool status). Un pool degradado puede retrasar la escritura del lock y generar los síntomas descritos.
  • Mantener una copia de /etc/pve/datacenter.cfg antes de modificar shell_timeout facilita revertir cambios si prefieres volver al comportamiento por defecto.
  • Cuando trabajes con contenedores LXC, recuerda que el lock se gestiona en el host, no dentro del contenedor. Ejecuta los pasos de liberación de lock desde el host.