InforSupports

Autor: Francisco

  • Diagnóstico de bloqueos de apt: locks, debconf y deadlocks de systemd

    Un apt upgrade que se queda colgado rara vez tiene una sola causa — suele ser una cadena de bloqueos que se van destapando uno tras otro. Este es un caso real donde tres problemas distintos se encadenaron: un lock de dpkg, un bloqueo de debconf, y finalmente un deadlock real entre dos servicios de systemd provocado por needrestart.

    Cómo se encadenó el problema

    1. apt.systemd.daily tenía tomado el lock inicialmente — el timer automático de actualizaciones de Ubuntu/Debian corriendo en segundo plano, compitiendo por el mismo recurso que el apt upgrade manual.
    2. Al liberarse ese lock, apareció un bloqueo real en debconf, con el mensaje /var/cache/debconf/config.dat is locked by another process.
    3. Al actualizar libc6 (una librería base que usan prácticamente todos los procesos del sistema), needrestart intentó reiniciar automáticamente los servicios que dependían de ella — y quedó colgado a mitad de ese proceso.
    4. Esto generó un deadlock real entre Zabbix y MySQL: zabbix-server.service estaba en estado restart (running), mientras mysql.service quedó en start (waiting) — cada uno esperando indefinidamente al otro, sin que ninguno pudiera avanzar por sí solo.
    5. Cancelar manualmente los jobs colgados de systemd liberó el bloqueo, y apt pudo terminar correctamente.
    6. El sistema quedó estable, solo pendiente de un reinicio para cargar el nuevo kernel instalado durante la actualización.

    Por qué pasa esto: el rol de needrestart

    needrestart es una herramienta que, tras actualizar paquetes, detecta qué servicios en ejecución siguen usando versiones antiguas de librerías ya reemplazadas (típicamente detectando referencias a archivos .so borrados en memoria), y ofrece reiniciarlos automáticamente para que carguen las versiones nuevas. Es útil en general, pero cuando el paquete actualizado es algo tan fundamental como libc6, la lista de servicios a reiniciar puede ser larga — y si dos de esos servicios tienen una dependencia circular entre sí a nivel de arranque (como Zabbix, que necesita a MySQL corriendo, mientras MySQL en este caso quedó esperando por un recurso que Zabbix tenía tomado), el reinicio automático masivo puede desencadenar exactamente el tipo de deadlock que ocurrió aquí.

    Diagnóstico: ver quién tiene el lock

    sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock
sudo lsof /var/cache/debconf/config.dat

    lsof (list open files) muestra qué proceso tiene abierto un archivo específico — en este caso, los archivos de lock que usan dpkg y debconf para evitar que dos instancias se ejecuten simultáneamente y corrompan el estado de paquetes instalados. Si el comando devuelve un PID, ese es el proceso responsable del bloqueo.

    Detener los procesos automáticos de APT

    sudo systemctl stop apt-daily.service
sudo systemctl stop apt-daily-upgrade.service
sudo systemctl stop apt-daily.timer
sudo systemctl stop apt-daily-upgrade.timer

    Ubuntu y Debian ejecutan actualizaciones automáticas de índices de paquetes (y opcionalmente de seguridad) en segundo plano mediante estos timers. Si uno de ellos está corriendo justo cuando se intenta un apt upgrade manual, ambos procesos compiten por el mismo lock — deteniendo estos servicios temporalmente se elimina esa competencia.

    Limpiar procesos colgados

    sudo kill -9 <PID>

    Último recurso cuando un proceso relacionado con apt/dpkg queda genuinamente colgado (no avanza ni responde) — kill -9 lo termina de forma forzosa, sin darle oportunidad de limpiar sus propios recursos. Debe usarse con cuidado, solo tras confirmar con lsof o ps que el proceso realmente está detenido y no simplemente trabajando lento.

    Reparar el estado de dpkg

    sudo dpkg --configure -a
sudo apt -f install

    dpkg --configure -a retoma y completa la configuración de cualquier paquete que haya quedado a medias (por una interrupción, un lock forzado a matar, etc.). apt -f install («fix broken») resuelve dependencias rotas que hayan quedado como resultado.

    Ver y cancelar jobs pendientes en systemd

    # Listar jobs de systemd en curso o en espera
systemctl list-jobs

# Cancelar jobs específicos por su número de job (no PID de proceso)
sudo systemctl cancel 2421271 2421892

    Esto fue lo que realmente destrabó el problema en este caso. Un «job» de systemd es una operación de cambio de estado en curso sobre una unidad (arrancar, detener, reiniciar) — cuando dos jobs quedan esperándose mutuamente (como el restart de Zabbix esperando el start de MySQL, y viceversa por otra dependencia), systemctl list-jobs los muestra con su estado (running o waiting), y cancel con el número de job los elimina de la cola sin necesidad de matar procesos a nivel de sistema operativo.

    Reiniciar servicios manualmente si hace falta

    sudo systemctl restart mysql
sudo systemctl restart zabbix-server

    Tras romper el deadlock cancelando los jobs colgados, conviene reiniciar los servicios afectados manualmente, en el orden correcto de dependencia (la base de datos primero, el servicio que depende de ella después) para asegurar que ambos queden arriba de forma limpia.

    Validar el estado final

    sudo dpkg --configure -a
sudo apt -f install
sudo apt upgrade

    Repetir estos comandos confirma que ya no quedan paquetes a medio configurar ni dependencias rotas, y permite completar la actualización que originalmente se había colgado.

    Revisar servicios fallidos

    systemctl --failed

    Lista únicamente las unidades que quedaron en estado failed tras todo el proceso — un chequeo final rápido para confirmar que ningún otro servicio quedó afectado colateralmente por el deadlock o por los reinicios forzados.

    Reiniciar para cargar el kernel nuevo

    sudo reboot

    Cuando la actualización incluye un kernel nuevo (común en actualizaciones de libc6 y paquetes base), el sistema sigue corriendo con el kernel anterior en memoria hasta el próximo reinicio. No es urgente hacerlo de inmediato si el sistema está estable — se puede programar para una ventana de mantenimiento sin prisa.

    # Confirmar el kernel cargado después del reinicio
uname -r

    Resumen del flujo de diagnóstico

    1. Si apt no avanza: verificar locks con lsof sobre los archivos de dpkg y debconf.
    2. Detener los timers automáticos de apt-daily si están compitiendo por el lock.
    3. Si un proceso está genuinamente colgado (no solo lento), terminarlo con kill -9 tras confirmarlo.
    4. Reparar con dpkg --configure -a y apt -f install.
    5. Si el problema persiste tras esto, revisar systemctl list-jobs — puede haber un deadlock real entre servicios provocado por needrestart, especialmente tras actualizar librerías base como libc6.
    6. Cancelar los jobs colgados con systemctl cancel, reiniciar manualmente los servicios afectados en el orden correcto de dependencia, y validar con systemctl --failed.

  • Netcat (nc): la navaja suiza de redes, con ejemplos prácticos

    Netcat (nc) es una de las herramientas más versátiles para trabajar con redes en Linux — lee y escribe datos crudos a través de conexiones TCP o UDP, lo que la hace útil tanto para diagnóstico como para tareas puntuales de transferencia y prueba de conectividad.

    Escuchar en una interfaz y puerto específicos

    nc -l -s 192.168.1.100 -p 8080
    • -l — activa el modo escucha (el equipo actúa como servidor, esperando una conexión entrante)
    • -s — selecciona la IP de la interfaz específica donde escuchar (útil en equipos con varias interfaces de red)
    • -p — define el puerto de escucha

    Probar la conexión desde otra máquina

    echo "Hola desde el cliente" | nc 192.168.1.100 8080

    echo genera el mensaje, y lo canaliza (|) hacia nc, que se conecta al servidor escuchando en esa IP y puerto, enviando el texto como datos crudos por la conexión TCP.

    Verificar si un puerto está abierto (escaneo simple)

    nc -zv 192.168.1.100 22

    -z hace que nc solo verifique si la conexión se puede establecer, sin enviar ni recibir datos (modo «zero-I/O», ideal para pruebas rápidas). -v activa el modo detallado (verbose), mostrando si la conexión tuvo éxito o fue rechazada.

    También se puede escanear un rango de puertos:

    nc -zv 192.168.1.100 20-25

    Transferir un archivo entre dos equipos

    Netcat no tiene protocolo propio de transferencia — simplemente mueve bytes crudos de un lado a otro, así que sirve perfectamente para mover un archivo completo sin necesidad de configurar SSH, FTP o Samba para una tarea puntual.

    En la máquina que recibe (destino):

    nc -l -p 9000 > archivo_recibido.tar.gz

    En la máquina que envía (origen):

    nc 192.168.1.100 9000 < archivo_original.tar.gz

    El destino queda escuchando y redirige todo lo que reciba directamente a un archivo; el origen se conecta y envía el contenido del archivo como flujo de datos. Al terminar la transferencia, ambos procesos de nc se cierran automáticamente.

    Banner grabbing: identificar qué servicio corre en un puerto

    Muchos servicios (SSH, SMTP, FTP) envían un mensaje de bienvenida (banner) apenas se conectan, que suele revelar la versión del software corriendo:

    nc -v 192.168.1.100 22

    Al conectar, el servicio SSH normalmente responde de inmediato con algo como SSH-2.0-OpenSSH_9.6, sin necesidad de autenticarse — útil para inventariar rápidamente qué versión de software corre un servidor.

    Chat simple entre dos terminales

    Como nc simplemente pasa lo que se escribe en la entrada estándar hacia la conexión, se puede usar como un chat rudimentario de ida y vuelta entre dos equipos:

    Equipo A (escucha):

    nc -l -p 5000

    Equipo B (se conecta):

    nc 192.168.1.100 5000

    Cualquier cosa que se escriba en cualquiera de las dos terminales (tras presionar Enter) aparece en la otra, en tiempo real.

    Modo UDP

    Por defecto nc usa TCP; para trabajar con UDP se agrega la bandera -u:

    # Escuchar en UDP
nc -u -l -p 8080

# Enviar en UDP
echo "mensaje UDP" | nc -u 192.168.1.100 8080

    Notas de seguridad

    • Netcat transmite todo en texto plano, sin cifrado — nunca usarlo para mover datos sensibles a través de redes no confiables; para eso existen herramientas como scp, rsync sobre SSH, o un túnel SSH.
    • Dejar un nc -l escuchando indefinidamente en un puerto expuesto a internet es un riesgo — cualquiera que se conecte puede enviar o recibir datos sin autenticación alguna.
    • Algunas variantes de nc (como ncat, incluida en el paquete Nmap) sí soportan cifrado SSL/TLS agregando la bandera --ssl, si se necesita algo más seguro manteniendo la misma simplicidad de uso.