Servidores Ubuntu 24.04: Snap vs apt — dónde Snap causa dolor silencioso (y qué hacer)

Snap vs apt en una página: qué cambia en un servidor

apt instala paquetes Debian (.deb) desde repositorios APT. Los archivos quedan en las ubicaciones normales del sistema de archivos,
las librerías se comparten, las actualizaciones las controla tu política de APT y las herramientas de gestión de configuración llevan 20 años aprendiendo el baile.
Cuando actualizas, actualizas todo el grafo de dependencias que el repositorio ofrece en ese momento. Puedes fijar versiones, mantener paquetes y preparar actualizaciones.

Snap instala imágenes squashfs más una capa de runtime (snapd). Cada aplicación es más autocontenida, incluye más de sus dependencias
y se ejecuta bajo confinamiento (perfiles AppArmor, espacios de nombres de montaje, integración con cgroups, etc.). Las actualizaciones son principalmente impulsadas por
snap refresh (automáticas por defecto), y las aplicaciones pueden actualizarse independientemente del resto del SO.
Esa separación es a la vez la ventaja y el problema.

Realidad del servidor, no marketing

• Control operativo: apt es “tu gestión de cambios”; Snap es “tu gestión de cambios más una segunda gestión”.
  Si no las alineas deliberadamente, acabarás tropezando con la deriva.
• Disco y montajes: Snap añade dispositivos loop y puntos de montaje. Eso no es intrínsecamente malo, pero cambia lo que significa “df muestra lleno” y cómo
  algunas herramientas se comportan bajo presión.
• Modelo de seguridad: el confinamiento puede reducir el radio de impacto, pero también rompe asunciones sobre rutas del sistema de archivos, sockets y acceso a recursos del host.
• Dependencia de red: Snap espera comunicarse con el Snap Store. Proxies, inspección TLS, entornos air-gapped y la restricción de salida lo hacen… entretenido.

Mi sesgo: en servidores de producción, por defecto prioriza apt salvo que Snap te ofrezca una ventaja concreta, auditada y operable.
“Era el predeterminado en la imagen de instalación” no es una ventaja. Es solo entropía con un logo.

Broma #1: Snap es como un minibar—conveniente hasta que revisas la factura y descubres que estuviste pagando por botellitas de cosas que ya tenías.

Hechos e historia que realmente importan

Esto no son datos para un trivial. Es el contexto que explica por qué tu servidor Ubuntu 24.04 se comporta distinto a tu modelo mental.

1. Snap empezó como “snappy” para Ubuntu Core e IoT, donde las actualizaciones atómicas y el empaquetado de apps son características, no molestias.
   Los servidores heredaron ese enfoque de empaquetado más tarde, a veces sin las mismas restricciones.
2. snapd se ejecuta como servicio del sistema y gestiona montajes, confinamiento y la planificación de refresh. En un servidor mínimo, es otro demonio
   con sus propios logs, temporizadores y modos de fallo.
3. Los snaps son imágenes squashfs montadas vía dispositivos loop. Por eso ves dispositivos extra /dev/loop* y montajes bajo /snap.
4. Se conservan revisiones de Snap para revertir (típicamente varias revisiones). Eso es útil cuando un refresh te rompe, y también una razón por la que el uso de disco crece silenciosamente.
5. El refresh es transaccional a nivel de Snap. Normalmente obtienes “la revisión antigua funciona” o “la nueva revisión funciona”, lo cual es genial—hasta que el refresh ocurre
   en tu hora de mayor carga.
6. Canonical ha impulsado ciertas aplicaciones hacia distribución Snap-primero con el tiempo. El ejemplo clásico son los navegadores en escritorios; en servidores, la presión aparece
   cuando “el paquete que esperabas” es reemplazado o quedado obsoleto.
7. El confinamiento de Snap depende en gran medida de AppArmor. Si deshabilitas AppArmor o ejecutas en contextos de seguridad inusuales, el modelo de seguridad de Snap puede degradarse o fallar de formas extrañas.
8. systemd se integra con Snap mediante unidades generadas y servicios gestionados por snapd. Tu suposición habitual de “el archivo de unidad vive en /etc/systemd/system” puede ser incorrecta.

Una idea parafraseada que se mantiene en ops: la esperanza no es estrategia. — atribuida al General Gordon R. Sullivan (parafraseado).
Las decisiones de empaquetado son estrategia. O la eliges, o la heredas.

Dónde Snap causa dolor silencioso (modos reales de fallo)

1) Actualizaciones sorpresa en medio del tráfico

Snap refresh es automático por diseño. El comportamiento por defecto es aceptable en un portátil. En un servidor, “aceptable” es sinónimo de “eventualmente te harán un pager.”
El refresh puede reiniciar servicios, rotar binarios y cambiar el comportamiento bajo una carga en ejecución.

Lo insidioso no es que ocurran actualizaciones. Es que ocurren fuera del camino de control de cambios que tu equipo ya sigue para apt,
gestión de configuración y ventanas de mantenimiento.

2) Uso de disco que crece sin parecer que crece

Snap mantiene múltiples revisiones y almacena datos bajo /var/snap y /var/lib/snapd.
Si usas volúmenes root pequeños (común en imágenes cloud), Snap puede empujarte a “root 100% lleno” más rápido de lo que esperas.
Mientras tanto df muestra más ruido por los montajes de las imágenes snap.

El modo de fallo es clásico: falla la rotación de logs, journald no puede escribir, fallan operaciones de paquetes y luego algo importante se cae.
Snap no es el único culpable, pero es un contribuidor silencioso común porque no se percibe como “datos de la app” al revisar rápidamente el uso de disco.

3) El confinamiento rompe asunciones de integración

Los snaps están en sandbox. Genial. Pero “sandbox” significa “tu app no puede ver el host como crees”.
Puntos de dolor comunes:

• Acceso a rutas /etc y /var que asumes que existen (o son escribibles).
• Bind a puertos privilegiados o uso de la red del host de maneras inesperadas según el snap y las conexiones de interfaces.
• Lectura de certificados del host, claves SSH o bundles CA desde ubicaciones estándar cuando el snap usa los suyos.
• Comunicación con sockets del host (socket de Docker, activación por socket de systemd, sockets Unix personalizados) sin las interfaces adecuadas.

En revisiones de incidentes esto suele aparecer como: “Pero el archivo de configuración está correcto.” Sí. El proceso simplemente no puede leerlo.

4) Deriva de observabilidad: logs, rutas y unidades de servicio no están donde esperas

Con apt, sabes dónde vive la unidad, dónde aterrizan los logs y dónde parchear configs. Snap abstrae esos detalles y a veces los reubica.
Es manejable, pero te ralentiza bajo presión.

5) Dependencia de la tienda y comportamiento de la flota en redes restringidas

Si tus servidores están detrás de reglas estrictas de egress, proxies o inspección TLS, snap refresh puede fallar repetidamente.
Los fallos repetidos pueden causar:

• Temporizadores persistentes que se despiertan y hacen trabajo (spam de logs, wakeups de CPU).
• Refresh atascados que bloquean otras operaciones.
• Deriva parcial de la flota: algunas máquinas se actualizan, otras no, y obtienes “misma versión” en postmortems de mentira.

6) Sobrecarga de montajes y dispositivos loop en entornos frágiles

La mayoría de servidores no se preocuparán por unos cuantos montajes extra. Algunos sí:

• Sistemas con asunciones estrictas de espacios de nombres de montaje (algunos contenedores, herramientas basadas en chroot o scripts de hardening).
• Monitorización heredada que trata “más dispositivos loop” como “alguien está minando crypto.”
• Hosts con límites estrictos en dispositivos loop o comportamientos raros de initramfs.

7) “Pero funcionó ayer” porque el runtime cambió

Las actualizaciones de Snap pueden traer nuevos runtimes y bases (por ejemplo, snaps core). Eso puede cambiar sutilmente el comportamiento TLS, los cifrados por defecto
o el comportamiento de librerías empaquetadas. No lo verás en el historial de apt. Lo verás como un error de handshake del cliente y una sensación creciente de fatalidad.

Broma #2: Cuando Snap dice que está “refreshing”, no está ofreciendo a tu servidor un día de spa—está redecorando la cocina mientras el servicio de cena está en marcha.

Tareas prácticas: comandos, salidas y decisiones (12+)

A continuación hay tareas que puedes ejecutar en Ubuntu 24.04 ahora mismo. Cada una incluye: un comando, salida realista, qué significa y la decisión que tomas.
Están escritas para personas que tienen que arreglar cosas, no debatir filosofía de empaquetado.

Tarea 1: Identificar si Snap está instalado y activo

cr0x@server:~$ systemctl status snapd --no-pager
● snapd.service - Snap Daemon
     Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-29 08:11:22 UTC; 2h 14min ago
TriggeredBy: ● snapd.socket
   Main PID: 1123 (snapd)
      Tasks: 14 (limit: 18956)
     Memory: 54.7M
        CPU: 1min 12.333s
     CGroup: /system.slice/snapd.service
             └─1123 /usr/lib/snapd/snapd

Qué significa: snapd está en ejecución y habilitado. Los refreshes y montajes de Snap están en juego.

Decisión: Si este es un servidor de producción y Snap no es explícitamente requerido, planifica eliminar/deshabilitarlo o bloquear el comportamiento de refresh.

Tarea 2: Listar snaps instalados (y detectar paquetes “sorpresa”)

cr0x@server:~$ snap list
Name        Version           Rev   Tracking       Publisher   Notes
core22      20241001          1380  latest/stable  canonical✓  base
lxd         5.21              33110 5.21/stable    canonical✓
snapd       2.63.1            23159 latest/stable  canonical✓  snapd

Qué significa: Estás ejecutando LXD desde Snap, además de la base y snapd.

Decisión: Confirma la propiedad: ¿tu equipo de plataforma soporta LXD como snap? Si no, migra a paquetes apt (cuando estén disponibles) o documenta Snap como dependencia.

Tarea 3: Ver cuándo Snap se refrescará próximo (y si está bloqueado)

cr0x@server:~$ snap refresh --time
timer: 00:00~24:00/4
last: today at 06:17 UTC
next: today at 10:19 UTC

Qué significa: Snap refresh puede ocurrir en cualquier momento del día, aproximadamente cada 4 horas, según la política.

Decisión: En servidores, configura una ventana de refresh alineada a tu ventana de mantenimiento, o mantén refresh temporalmente durante eventos críticos.

Tarea 4: Establecer una ventana de refresh (control de ventana de mantenimiento)

cr0x@server:~$ sudo snap set system refresh.timer=Sun03:00-05:00

Qué significa: Snap intentará refrescar durante el domingo 03:00–05:00.

Decisión: Usa una ventana que coincida con la realidad del on-call. Si tu ventana de mantenimiento es “nunca”, tu sistema ya está funcionando con corazonadas.

Tarea 5: Mantener refresh durante una congelación (corto plazo, no para siempre)

cr0x@server:~$ sudo snap refresh --hold=24h
General refreshes of "all snaps" held until 2025-12-30T08:33:10Z

Qué significa: Has pausado los refreshes por 24 horas.

Decisión: Usa esto durante la respuesta a incidentes o lanzamientos importantes. Crea un ticket de seguimiento para quitar la retención y parchear intencionalmente.

Tarea 6: Comprobar si un snap refresh reinició recientemente un servicio

cr0x@server:~$ journalctl -u snapd --since "today" --no-pager | tail -n 12
Dec 29 06:16:59 server snapd[1123]: Refreshing "lxd"
Dec 29 06:17:21 server snapd[1123]: Restarted snap.lxd.daemon.service
Dec 29 06:17:22 server snapd[1123]: Refreshing "core22"
Dec 29 06:17:35 server snapd[1123]: Finished refresh, 2 snaps updated

Qué significa: LXD fue refrescado y su daemon reiniciado.

Decisión: Si no programaste ese reinicio, ajusta los controles de refresh y añade monitorización para reinicios iniciados por snaps.

Tarea 7: Identificar unidades systemd gestionadas por snap

cr0x@server:~$ systemctl list-units --type=service | grep -E '^snap\.'
snap.lxd.activate.service          loaded active exited  Service for snap application lxd.activate
snap.lxd.daemon.service            loaded active running Service for snap application lxd.daemon
snap.snapd.apparmor.service        loaded active exited  Load AppArmor profiles managed internally by snapd

Qué significa: Estas son unidades generadas por snap; editarlas directamente suele ser la jugada equivocada.

Decisión: Usa los ajustes de configuración de snap o drop-ins de systemd (con cuidado) y documenta lo que está soportado.

Tarea 8: Entender los dispositivos loop y montajes que añade Snap (ruido de disco/montaje)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MOUNTPOINT | grep -E 'loop|NAME'
NAME   TYPE   SIZE MOUNTPOINT
loop0  loop  74.2M /snap/core22/1380
loop1  loop  95.3M /snap/lxd/33110
loop2  loop  53.6M /snap/snapd/23159

Qué significa: Cada revisión de snap es una imagen squashfs montada vía loop.

Decisión: No “limpies dispositivos loop” manualmente. Si el disco está justo, reduce las revisiones retenidas y elimina snaps no utilizados.

Tarea 9: Medir cuánto espacio usa Snap (y dónde)

cr0x@server:~$ sudo du -sh /var/lib/snapd /var/snap 2>/dev/null
1.3G	/var/lib/snapd
612M	/var/snap

Qué significa: Estás gastando ~2 GB en la infraestructura de Snap y datos de apps snap.

Decisión: En volúmenes root pequeños, o presupuestas espacio para Snap o elimínalo. Si lo mantienes, configura retención y monitorea /var.

Tarea 10: Reducir revisiones retenidas (control de disco)

cr0x@server:~$ sudo snap set system refresh.retain=2

Qué significa: Snap conservará menos revisiones antiguas (el valor por defecto suele ser mayor).

Decisión: Fija retain a 2 en servidores a menos que tengas una política fuerte de rollback que requiera más y tu presupuesto de disco lo soporte.

Tarea 11: Revertir un snap tras un mal refresh

cr0x@server:~$ sudo snap revert lxd
lxd reverted to 5.21

Qué significa: Has revertido a la revisión previa que snapd mantuvo.

Decisión: Trata el revert como un paso de estabilización. Luego: congelar refresh, abrir un incidente y planear una corrección controlada hacia adelante.

Tarea 12: Encontrar conexiones de interfaces de Snap (por qué acceso denegado)

cr0x@server:~$ snap connections lxd | head
Interface  Plug            Slot                 Notes
network    lxd:network     :network             -
network-bind lxd:network-bind :network-bind     -
mount-observe lxd:mount-observe :mount-observe  -

Qué significa: Los snaps usan interfaces para permisos. Conexiones faltantes pueden causar “permission denied” incluso para servicios ejecutados como root.

Decisión: Si un snap no puede acceder a algo, revisa interfaces antes de reescribir permisos. Usa snap connect solo cuando entiendas la compensación de seguridad.

Tarea 13: Detectar temporizadores de refresh de snap y qué harán

cr0x@server:~$ systemctl list-timers --all | grep -E 'snap|apt' | head -n 20
snapd.refresh.timer         loaded active waiting   Tue 2025-12-29 10:19:00 UTC  1h 41min left
apt-daily.timer             loaded active waiting   Tue 2025-12-29 06:12:41 UTC  21h left
apt-daily-upgrade.timer     loaded active waiting   Tue 2025-12-29 06:27:10 UTC  21h left

Qué significa: Tienes dos planificadores de actualizaciones independientes: apt timers y el temporizador de refresh de snapd.

Decisión: Alinea ambos con tu plan de mantenimiento. Si usas un sistema de parcheo centralizado, considera deshabilitar temporizadores por defecto y dirigir actualizaciones explícitamente.

Tarea 14: Confirmar si un comando dado es un snap, no un deb

cr0x@server:~$ command -v lxd
/snap/bin/lxd

Qué significa: Estás ejecutando el binario proporcionado por snap, no uno instalado por apt.

Decisión: En runbooks, registra rutas. En incidentes, verifica qué binario está ejecutándose antes de asumir ubicaciones de configuración y rutas de actualización.

Tarea 15: Comprobar equivalentes apt y qué está instalado

cr0x@server:~$ apt-cache policy lxd | sed -n '1,12p'
lxd:
  Installed: (none)
  Candidate: 1:0.0~git20240301.abcdef-0ubuntu1
  Version table:
     1:0.0~git20240301.abcdef-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

Qué significa: LXD está disponible vía apt, pero no instalado. Estás ejecutando el snap.

Decisión: Decide un canal de empaquetado por servicio. Las instalaciones mixtas son la forma de obtener bugs fantasma y comportamiento “depende del host”.

Tarea 16: Eliminar un snap limpiamente (si eliges apt-primero)

cr0x@server:~$ sudo snap remove --purge lxd
Remove "lxd" snap
lxd removed

Qué significa: El paquete snap y sus datos fueron eliminados (purge).

Decisión: Haz esto solo después de migrar datos y validar el plan de despliegue basado en apt. Purge no es “a lo mejor”. Purge es “lo digo en serio”.

Tarea 17: Deshabilitar snapd (si debes mantener el paquete pero detener el comportamiento)

cr0x@server:~$ sudo systemctl disable --now snapd.service snapd.socket
Removed "/etc/systemd/system/multi-user.target.wants/snapd.service".
Removed "/etc/systemd/system/sockets.target.wants/snapd.socket".

Qué significa: snapd se detiene y no se auto-iniciará vía socket.

Decisión: Si hay componentes críticos como snaps, esto los romperá. Usa esto solo cuando hayas verificado que el host está libre de snaps o estés dispuesto a asumir el impacto.

Tarea 18: Comprobar que snapd ya no es funcional (verificación)

cr0x@server:~$ snap list
error: cannot communicate with server: Post "http://localhost/v2/snaps": dial unix /run/snapd.socket: connect: no such file or directory

Qué significa: El cliente snap no puede hablar con snapd. Bien—si eso es lo que querías.

Decisión: Actualiza tus comprobaciones base y las imágenes doradas para no terminar con hosts medio gestionados.

Guía de diagnóstico rápido: qué revisar primero/segundo/tercero

Esta es la secuencia “está en llamas y tengo 15 minutos” para el dolor relacionado con Snap en servidores Ubuntu 24.04.
El objetivo no es ser elegante. El objetivo es ser correcto rápidamente.

Primero: ¿Algo se refrescó o reinició?

• Comprueba el timing de refresh de snap:

  cr0x@server:~$ snap refresh --time
  timer: 00:00~24:00/4
  last: today at 06:17 UTC
  next: today at 10:19 UTC

  Interpretación: Si last coincide con el inicio del incidente, sospecha de un cambio inducido por refresh.

• Revisa logs de snapd por reinicios:

  cr0x@server:~$ journalctl -u snapd --since "today" --no-pager | grep -E 'Refreshing|Restarted' | tail -n 20
  Dec 29 06:16:59 server snapd[1123]: Refreshing "lxd"
  Dec 29 06:17:21 server snapd[1123]: Restarted snap.lxd.daemon.service

  Interpretación: Snap hizo algo. Ahora debes decidir si revertir/congelar.

Segundo: ¿El problema es disco, CPU, red o permisos?

• Presión de disco (root/var):

  cr0x@server:~$ df -h / /var
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/vda1        30G   28G  1.2G  96% /
  /dev/vda1        30G   28G  1.2G  96% /var

  Interpretación: Estás a un pico de logs de un mal día. La retención de Snap y /var/lib/snapd son sospechosas principales.

• CPU en churn por intentos de refresh:

  cr0x@server:~$ top -b -n 1 | head -n 12
  top - 10:41:10 up  1 day,  2:30,  1 user,  load average: 1.21, 1.05, 0.88
  Tasks: 231 total,   1 running, 230 sleeping,   0 stopped,   0 zombie
  %Cpu(s):  9.0 us,  2.1 sy,  0.0 ni, 88.2 id,  0.3 wa,  0.0 hi,  0.4 si,  0.0 st
  MiB Mem :  3906.7 total,   612.3 free,  1298.4 used,  1996.0 buff/cache
  MiB Swap:  2048.0 total,  2048.0 free,     0.0 used.  2340.1 avail Mem
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     1123 root      20   0 1349808  56032  19840 S   6.0   1.4   1:12.33 snapd

  Interpretación: snapd está consumiendo CPU. Si esto coincide con bucles de refresh o problemas de conectividad con la tienda, arregla la red/proxy y fija una ventana de refresh.

• Problemas de permisos o confinamiento:

  cr0x@server:~$ journalctl -u snap.lxd.daemon --since "today" --no-pager | tail -n 8
  Dec 29 06:18:04 server lxd[14555]: Error: failed to open /etc/lxd/cluster.crt: permission denied
  Dec 29 06:18:04 server lxd[14555]: Error: daemon failed to start

  Interpretación: El servicio no puede acceder a una ruta del host. Revisa interfaces y expectativas de confinamiento antes de “arreglar” permisos a lo loco.

Tercero: Estabiliza, luego decide estrategia de canal

• Estabiliza: mantén refresh y revierte si es necesario.

  cr0x@server:~$ sudo snap refresh --hold=24h
  General refreshes of "all snaps" held until 2025-12-30T10:44:22Z

• Decide: mantener Snap pero operarlo (ventanas, monitorización, retención), o eliminarlo y estandarizar en apt.

Tres micro-relatos corporativos desde el frente

Micro-relato #1: El incidente causado por una suposición errónea

Una empresa mediana operaba una flota de servidores Ubuntu que alojaban herramientas internas de desarrollo: mirrors de artefactos, runners CI y un pequeño clúster LXD para entornos de prueba efímeros.
Eran buenos parcheando: las actualizaciones apt se desplegaban en ondas semanales, con canarios, dashboards y una persona vigilando los presupuestos de error.

Durante un sprint intenso, los desarrolladores empezaron a quejarse de que los contenedores LXD fallaban al iniciarse en un subconjunto de hosts. El ingeniero on-call revisó el historial de apt y no encontró nada.
El repositorio de configuración no había cambiado. CPU y memoria estaban bien. Los hosts parecían “idénticos” en papel.

La suposición equivocada fue simple: “Si está instalado, lo gestiona apt.” En realidad, LXD estaba instalado vía Snap en esas imágenes porque alguien siguió una guía upstream meses atrás.
Snap refrescó LXD en algunos hosts esa misma mañana, reiniciando el daemon. La nueva revisión endureció una regla de confinamiento y el daemon dejó de leer una ruta de certificados que vivía fuera del acceso permitido del snap.

La solución fue rápida una vez que entendieron lo que pasaba: snap revert para estabilizar, snap refresh --hold para detener la inestabilidad, y luego una solución adecuada de interfaces/rutas.
El trabajo real fue el postmortem: añadieron una comprobación base en el provisioning que marcaba cualquier host con snaps inesperados instalados, y documentaron “canales de empaquetado soportados” para servicios críticos.

Nadie fue despedido. Pero se reescribieron varios runbooks con menos optimismo y más comandos.

Micro-relato #2: La optimización que salió mal

Otra organización tenía un proyecto de reducción de costos: volúmenes root más pequeños en instancias cloud, envío agresivo de logs y una consigna de “mantener el SO mínimo”.
Cambiaron algunas herramientas a snaps porque las apps eran autocontenidas y “reducirían el lío de dependencias”. Esa parte era cierta.

El problema vino de matemáticas básicas. Las revisiones de snap se acumularon en una flota que rara vez se reiniciaba y casi nunca tenía mantenimiento manual.
Entre /var/lib/snapd, revisiones antiguas y datos de aplicaciones bajo /var/snap, máquinas con raíces de 20–30 GB empezaron a rondar el 90% de uso.
No suficiente para alertar. Suficiente para ser frágil.

Luego un incidente de vecino ruidoso provocó picos de logs. Algunos hosts pasaron a 100% usado, journald dejó de escribir, los checks de salud comenzaron a expirar y el orquestador empezó a reschedular cargas.
El rescheduling calentó a los hosts restantes y un problema aburrido de disco se convirtió en una falla en cascada que parecía “inestabilidad aleatoria de servicios”.

Su “optimización” fue reducir la complejidad de la imagen base. La realidad fue que introdujeron una segunda caché de empaquetado con su propio comportamiento de retención y no la presupuestaron.
Lo arreglaron fijando refresh.retain=2, moviendo algunos datos fuera de volúmenes root y—esto es lo que la gente suele omitir—añadiendo un dashboard que desglosara el uso de disco por categoría,
incluyendo rutas gestionadas por Snap. Si no lo graficas, seguirá llenándose. Solo que lo hará en silencio.

Micro-relato #3: La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros operaba servidores Ubuntu con ventanas de cambio estrictas. No eran anti-Snap, pero trataban Snap como cualquier otra fuente de cambio:
programarlo, observarlo y hacerlo reversible.

Su baseline incluía:
una ventana de refresh alineada al mantenimiento dominical,
retención de refresh establecida en 2,
monitorización de reinicios de la unidad snapd,
y un trabajo CI simple que comparaba la salida de snap list en toda la flota para detectar deriva.
Nada sofisticado. Solo disciplina.

Un fin de semana, una actualización de snap introdujo un cambio de comportamiento en un agente de monitorización. Unas pocas canarias se actualizaron primero (porque las ventanas de refresh estaban escalonadas por grupo).
Los dashboards señalaron el cambio inmediatamente: la tasa de reconexión del agente cayó, la CPU subió ligeramente y los logs mostraron una nueva firma de advertencia.

Porque el equipo tenía un camino operativo, la respuesta fue aburrida: congelar refresh en la flota, revertir en las canarias, abrir ticket interno con el proveedor y volver a probar en staging. Producción no vio impacto general.

Así es como se ve la ingeniería de fiabilidad la mayoría de los días: previenes la emoción. Es profundamente poco sexy. Funciona.

Errores comunes: síntoma → causa raíz → arreglo

1) Síntoma: “Servicio se reinició solo”

Causa raíz: snap refresh reinició una unidad systemd gestionada por snap.

Arreglo: Configura refresh.timer a una ventana de mantenimiento; monitoriza reinicios de snapd; considera congelar refresh durante eventos críticos.

2) Síntoma: “El sistema root se llena lentamente aunque los datos de la app estén en otro sitio”

Causa raíz: Revisiones de Snap y datos bajo /var/lib/snapd y /var/snap.

Arreglo: Fija refresh.retain a 2; elimina snaps no usados; presupuestar espacio; monitorea explícitamente las rutas de Snap.

3) Síntoma: “Permission denied leyendo /etc/… incluso como root”

Causa raíz: Confinamiento de Snap y conexiones de interfaces faltantes; el proceso corre en un contexto restringido.

Arreglo: Usa snap connections para inspeccionar; ajusta la configuración a rutas aprobadas por snap; conecta solo las interfaces necesarias con conocimiento de la compensación.

4) Síntoma: “snap refresh sigue fallando, logs llenos, CPU despierta”

Causa raíz: Egress restringido, problemas de proxy, inspección TLS o DNS que bloquean el acceso a la tienda.

Arreglo: Valida la conectividad saliente; configura el proxy para snapd; si no puedes soportar el acceso a la tienda, no ejecutes snaps en ese entorno.

5) Síntoma: “La monitorización muestra muchos dispositivos loop; alguien entra en pánico por compromiso”

Causa raíz: Comportamiento normal de Snap: cada revisión monta una imagen squashfs como dispositivo loop.

Arreglo: Educa a la monitorización y a las personas; alerta por uso de disco y eventos de refresh, no por la mera existencia de dispositivos loop.

6) Síntoma: “Actualizamos vía apt, pero el binario en ejecución no cambió”

Causa raíz: El binario viene de /snap/bin y no está gestionado por apt.

Arreglo: Comprueba command -v, estandariza el canal de empaquetado y aplícalo en el provisioning.

7) Síntoma: “Los overrides de systemd no funcionan”

Causa raíz: Las unidades generadas por snap pueden regenerarse; editar la unidad directamente es frágil.

Arreglo: Usa drop-ins con cuidado; prefiere opciones de configuración de snap; documenta qué cambios sobrevivirán a un refresh.

8) Síntoma: “La misma app, diferente comportamiento entre hosts”

Causa raíz: Deriva por refresh de Snap (revisiones distintas), especialmente en flotas sin ventanas de refresh consistentes o con refresh fallidos en algunos nodos.

Arreglo: Compara snap list en la flota; aplica ventanas de refresh; alerta sobre desalineación de versiones; para servicios críticos considera apt con versiones fijadas.

Listas de comprobación / plan paso a paso

Plan A: Mantienes Snap (pero opéralo conscientemente)

1. Inventario de snaps en cada rol de servidor.

   cr0x@server:~$ snap list
   Name   Version   Rev   Tracking       Publisher   Notes
   snapd  2.63.1    23159 latest/stable  canonical✓  snapd

   Decisión: Si un rol tiene snaps que no esperabas, párate y decide la propiedad.

2. Establece una ventana de refresh alineada al mantenimiento.

   cr0x@server:~$ sudo snap set system refresh.timer=Sun03:00-05:00
   

   Decisión: Pon las actualizaciones donde hay humanos.

3. Reduce la retención a menos que el disco abunde.

   cr0x@server:~$ sudo snap set system refresh.retain=2
   

   Decisión: Si quieres “rollback infinito”, compra “disco infinito”. Si no, mantenlo ajustado.

4. Alerta por reinicios de snapd y reinicios de servicios gestionados por snap.

   cr0x@server:~$ systemctl list-units --type=service | grep -E '^snap\.'
   snap.snapd.apparmor.service        loaded active exited  Load AppArmor profiles managed internally by snapd

   Decisión: Trata el refresh como despliegues. Ponlos en superficie.

5. Documenta expectativas de confinamiento para cada snap (rutas, sockets, puertos).

   cr0x@server:~$ snap connections snapd | head
   Interface  Plug         Slot           Notes
   network    snapd:network :network      -
   

   Decisión: Si tu app necesita integración con el host más allá de interfaces estándar, reconsidera Snap para esa app.

6. Ejecuta canarias: escalona ventanas de refresh por grupo.

   Decisión: Quieres un radio de blast pequeño cuando la siguiente actualización sea “interesante”.

Plan B: Vas apt-primero (recomendado para la mayoría de servidores de producción)

1. Encuentra binarios provistos por snap en tu path operativo.

   cr0x@server:~$ command -v lxd
   /snap/bin/lxd

   Decisión: Si tu runtime crítico está bajo /snap/bin, planifica la migración antes de la eliminación.

2. Migra servicio por servicio (no arranques sacando snapd primero).

   cr0x@server:~$ snap list
   Name  Version  Rev  Tracking       Publisher   Notes
   lxd   5.21     33110 5.21/stable   canonical✓

   Decisión: Elimina un snap a la vez, verifica la funcionalidad y luego continúa.

3. Elimina snaps limpiamente una vez migrados.

   cr0x@server:~$ sudo snap remove --purge lxd
   Remove "lxd" snap
   lxd removed

   Decisión: Purge borra datos. Haz backups primero.

4. Deshabilita snapd cuando el host esté libre de snaps.

   cr0x@server:~$ sudo systemctl disable --now snapd.service snapd.socket
   Removed "/etc/systemd/system/multi-user.target.wants/snapd.service".
   Removed "/etc/systemd/system/sockets.target.wants/snapd.socket".

   Decisión: Esto es una política. Hazla cumplir en tu imagen base.

5. Confirma propiedad apt y fija/pone en hold según sea necesario.

   cr0x@server:~$ apt-mark showhold
   

   Decisión: Para componentes críticos, usa pinning/holds de apt y despliegues controlados, no “lo que se actualizó último”.

6. Haz que sea difícil reintroducir Snap accidentalmente mediante imágenes doradas y comprobaciones CI.

   Decisión: La deriva de empaquetado es una regresión como cualquier otra. Pruébala.

Preguntas frecuentes

1) ¿Snap es “malo” para servidores?

No inherentemente. Es un segundo sistema de empaquetado con actualizaciones automáticas, confinamiento y dependencias de tienda.
Eso está bien cuando encaja con tu modelo operativo. En muchos servidores de producción, no—a menos que lo gestiones activamente.

2) ¿Cuál es el mayor riesgo de Snap en producción?

Cambio no coordinado. El auto-refresh que reinicia daemons fuera de tu ventana de mantenimiento es la forma número 1 en que Snap se convierte en un pager.
Arregla eso primero: ventanas de refresh, retenciones durante congelaciones y monitorización.

3) ¿Puedo simplemente desactivar el refresh de snap y olvidarme?

Puedes mantener refresh temporalmente y puedes restringir la programación del refresh. Pero congelar actualizaciones permanentemente es la forma de crear un problema de seguridad
con una interfaz bonita. Si no puedes parchear snaps de forma fiable, no ejecutes snaps para servicios críticos.

4) ¿Por qué Snap come espacio incluso cuando eliminé la app?

Snap conserva revisiones, y snapd más las bases ocupan espacio. Si solo eliminaste una app, puede que aún tengas snaps base.
Revisa snap list, du -sh /var/lib/snapd /var/snap y reduce refresh.retain.

5) ¿Por qué veo tantos dispositivos loop?

Cada snap es una imagen squashfs montada como dispositivo loop. Es normal.
La acción operativa no es “eliminar dispositivos loop”. Es “controlar cuántas revisiones se retienen” y “monitorear el uso de disco sensatamente”.

6) ¿Cuál es la forma más limpia de saber si un binario viene de Snap?

Usa command -v o which. Si está bajo /snap/bin, estás ejecutando el snap.
Luego revisa snap list para ver qué revisión y canal.

7) ¿Los snaps son más seguros por el confinamiento?

El confinamiento puede reducir el radio de impacto, sí. Pero la seguridad es una propiedad del sistema: también necesitas cadencia de parches que controles, observabilidad
y un modelo de red que soporte la tienda. Un deb bien gestionado puede ser más seguro que un snap que nunca actualizas.

8) ¿Qué pasa en entornos air-gapped o con egress restringido?

Asume que Snap será problemático a menos que tengas una estrategia offline soportada y hayas probado el comportamiento de refresh de punta a punta.
Si no puedes garantizar acceso a la tienda (directo o mediante un mecanismo aprobado), los repos apt que espejeas internamente suelen ser más simples y predecibles.

9) Si mantengo Snap, ¿qué controles mínimos debo aplicar?

Establece una ventana de refresh, reduce la retención, monitoriza reinicios de snapd y de unidades gestionadas por snap, y audita regularmente la deriva de versiones en la flota.
Si no puedes hacer eso, no “tienes Snap”—Snap te tiene a ti.

10) ¿Por qué la resolución de problemas se siente más lenta con Snap?

Porque el mapa mental cambia: las unidades pueden ser generadas, las ubicaciones de logs y datos pueden diferir, los errores de confinamiento parecen problemas de permisos
y las actualizaciones ocurren en un calendario separado. Una vez que tus runbooks incluyan comprobaciones específicas de Snap, será más fácil.

Próximos pasos prácticos

Decide si tus servidores son apt-primero o operados por Snap. No seas “lo que pasó históricamente”.
La estrategia mixta es donde los bugs se reproducen solo los viernes.

1. Inventario: ejecuta snap list en cada rol de servidor y registra lo instalado.
2. Control de cambios: si Snap existe, fija refresh.timer a una ventana real de mantenimiento y establece refresh.retain=2.
3. Monitorización: alerta sobre eventos de refresh de snapd y reinicios de unidades gestionadas por snap; grafica el crecimiento de /var/lib/snapd.
4. Estandariza: para servicios críticos, elige un canal, documéntalo y hazlo cumplir en la construcción de imágenes y comprobaciones CI.
5. Practica rollback: prueba snap revert y tu estrategia de rollback apt en staging para no aprender bajo presión.

Ubuntu 24.04 es una plataforma de servidor sólida. Snap puede ser parte de esa historia. Pero en servidores, la conveniencia no es una característica a menos que puedas operarla.
El mejor sistema de empaquetado es el que no te sorprende. El segundo mejor es el que puedes revertir antes de que los clientes lo noten.