El truco del ‘arranque limpio’: aisla la aplicación problemática en menos de 10 minutos

Qué significa realmente “arranque limpio” (y qué no)

Un arranque limpio no es “reinicia y reza”. Tampoco es “modo seguro”, aunque riman operativamente. Arranque limpio significa: iniciar el sistema con solo los componentes esenciales del SO y un conjunto deliberadamente pequeño de servicios, controladores y elementos de inicio. Luego vuelves a introducir el resto en lotes controlados hasta que el comportamiento problemático retorna.

En términos de producción, es una búsqueda binaria sobre tu ecosistema de tiempo de arranque y post-login.

El arranque limpio responde tres preguntas rápidamente

1. ¿Está enferma la capa OS/controlador? Si el problema persiste en un arranque mínimo, sospecha de controladores de kernel, sistema de archivos, hardware o configuración base del SO.
2. ¿Es un problema de capa de servicios? Si el arranque mínimo va bien pero el arranque normal no, sospecha de servicios, tareas programadas, elementos de inicio y software agente.
3. ¿Es específico del contexto de usuario? Si ocurre solo para un usuario, revisa elementos de inicio por usuario, scripts de inicialización del shell, autostart del escritorio y servicios por usuario.

Qué no es un arranque limpio

• No es una cura. Es una técnica de diagnóstico para aislar. Si te quedas aquí, el problema vuelve en el momento en que “restauras todo”.
• No es una licencia para desinstalar a lo loco. Desinstalar aplicaciones al azar es la forma de crear un segundo incidente: “¿por qué falló la VPN?”.
• No es solo para escritorios. Los servidores también tienen “elementos de inicio”; simplemente se llaman archivos de unidad, trabajos cron, scripts init y agentes secundarios.

La mentalidad de arranque limpio es la misma en todas partes: reduce variables. Si no puedes reducir variables, solo estás haciendo una danza interpretativa frente al canal de incidentes.

Guion de diagnóstico rápido: primeras/segundas/terceras comprobaciones

Este es el flujo de “tengo 10 minutos antes de la próxima reunión”. Está sesgado hacia encontrar el cuello de botella rápido, no hacia escribir una novela.

Primero: identifica el dolor del recurso dominante (30–90 segundos)

• ¿CPU al límite? Busca uno o unos pocos procesos consumiendo núcleos.
• ¿I/O de disco atascado? Observa lecturas/escrituras altas y profundidad de cola; muchos “arranques lentos” son en realidad “almacenamiento lento”.
• ¿Presión de memoria? Intercambio a disco durante el arranque hace que todo parezca roto.
• ¿Red colgada? DNS o portales cautivos pueden bloquear servicios que «amablemente» impiden el inicio.

Segundo: separa regresiones en tiempo de arranque vs post-login (1–2 minutos)

• Arranque lento: cadena crítica de systemd, inicialización de controladores, comprobaciones de sistema de archivos, volúmenes cifrados, timeouts DHCP.
• Post-login lento: servicios de usuario, aplicaciones de autostart del escritorio, clientes de sincronización, agentes de endpoint, restauración de sesiones del navegador.

Tercero: haz un arranque mínimo y compara (3–6 minutos)

• Si el arranque mínimo está limpio: el culpable es un servicio/agent/aplicación no esencial.
• Si el arranque mínimo sigue lento: sospecha actualizaciones del SO, módulos de kernel, problemas de sistema de archivos, hardware o configuración base.

Luego haces bisección: habilita la mitad de los sospechosos, reinicia (o reinicia la sesión de usuario), observa. Repite. Encontrarás al culpable más rápido que “desactivar una cosa a la vez” y con menos daños colaterales.

Un máximo de confiabilidad para tener en la mesa. Cito, parafraseando una idea de Werner Vogels: Todo falla; construye sistemas y hábitos que esperen fallos y se recuperen rápido.

Hechos e historia interesantes: por qué esto funciona

El arranque limpio parece un truco moderno, pero es básicamente el patrón de depuración más antiguo en computación: “comienza con un programa mínimo y añade complejidad hasta que se rompa”. Aquí hay puntos de contexto concretos que explican por qué es tan efectivo.

1. El arranque temprano de Unix era literalmente un script. SysV init usaba scripts de shell secuenciales en /etc/rc*, así que “desactivar elementos de inicio” significaba renombrar un enlace simbólico. La idea es anterior a la mayoría de las pilas de software actuales.
2. Windows popularizó el término “arranque limpio”. La idea se formalizó para aislar servicios de terceros y elementos de inicio sin entrar en modo seguro completo.
3. Systemd hizo medible el rendimiento de arranque. Con systemd-analyze, puedes cuantificar “qué se volvió más lento” en lugar de discutir por impresiones.
4. El tiempo de arranque a menudo está bloqueado por timeouts. Esperas por red-online, fallos de DNS y montajes faltantes pueden sumar 30–120 segundos cada uno. Una única unidad mal configurada puede dominar la línea de tiempo.
5. Los agentes de seguridad endpoint son infractores frecuentes. Enganchan rutas de sistema de archivos y red, por lo que su “pequeña sobrecarga” se vuelve enorme durante ráfagas de inicio con alta actividad.
6. La salud del SSD afecta el arranque de forma engañosa. Un disco con latencia alta por nivelado de desgaste o errores puede hacer que la CPU parezca ocupada mientras espera I/O.
7. Las actualizaciones de BIOS/UEFI y firmware cambiaron el juego. Los “problemas de arranque” modernos pueden empezar antes del SO, especialmente cuando Secure Boot, TPM o el firmware del controlador de almacenamiento se comportan mal.
8. La acumulación de autostart es institucional, no personal. Las empresas despliegan agentes para VPN, DLP, EDR, monitorización, chat y sincronización. Cada uno es racional por sí solo; juntos son una tragedia.
9. La búsqueda binaria vence a la búsqueda lineal. Si tienes 32 elementos de inicio, desactivar uno por uno son 32 ciclos. La bisección puede encontrar al culpable en ~5 ciclos.

Broma #1: Depurar tiempos de arranque es como la arqueología: cada capa que descubres contiene otra capa, y de alguna manera todo está cubierto de polvo de 2017.

Método en menos de 10 minutos (el flujo práctico)

Aquí está el flujo que uso cuando alguien dice “está lento” y lo que realmente quiere decir es “mi día está arruinado”. Asume una estación de trabajo/servidor Linux con systemd, pero la lógica se adapta bien a los launch agents de macOS y a los servicios de Windows.

Minuto 0–1: escribe el síntoma en términos medibles

• “Arranque hasta el prompt de login tarda 2 minutos en vez de 25 segundos.”
• “Tras el login, la CPU está al 400% durante 5 minutos.”
• “LED de disco encendido; abrir una terminal tarda 20 segundos.”

No te saltes esto. Sin una declaración de referencia, “arreglarás” algo y aún no sabrás si mejoraste algo.

Minuto 1–3: determina si es la canalización de arranque o post-login

Los problemas de la canalización de arranque aparecen en los registros del sistema y en los tiempos de systemd. Los problemas post-login aparecen como servicios a nivel de usuario, aplicaciones de autostart del escritorio y comportamientos de sincronización/escan.

Minuto 3–6: realiza el arranque limpio

En sistemas con systemd, el “arranque limpio” más rápido es usar un objetivo más mínimo (multi-user sin GUI), además de deshabilitar temporalmente servicios no esenciales. También puedes arrancar con una entrada de kernel diferente o añadir parámetros de kernel, pero primero mantenlo simple.

Minuto 6–10: bisecta e identifica al culpable

Vuelve a habilitar la mitad de los servicios/elementos de inicio deshabilitados y comprueba si el síntoma vuelve. Si vuelve, el culpable está en esa mitad. Si no vuelve, está en la otra mitad. Repite.

No intentes ser demasiado listo con la intuición. La intuición es como terminas culpando a lo equivocado y escribiendo un postmortem titulado “la lentitud misteriosa se resolvió sola”.

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

Estas son tareas reales que puedes ejecutar. Cada una incluye: comando, qué significa la salida y qué decisión tomar a continuación. Trátalo como tu kit de campo.

Task 1: See if this is CPU, memory, or I/O (top)

cr0x@server:~$ top -b -n 1 | head -n 20
top - 10:12:01 up  5:21,  1 user,  load average: 6.12, 5.90, 4.80
Tasks: 312 total,   3 running, 309 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.0 us,  4.0 sy,  0.0 ni, 72.0 id,  6.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  15948.5 total,    412.3 free,  11200.1 used,   4336.1 buff/cache
MiB Swap:   2048.0 total,   1800.0 free,    248.0 used.   3200.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 2345 root      20   0  167834  62120  13124 R  180.0   0.4   3:12.41 updatedb
 1988 root      20   0  912340  84212  30124 S   60.0   0.5   1:22.10 falcon-sensor

Qué significa: Aquí la CPU está activa, pero fíjate en wa (espera de I/O) en 6%. No es catastrófico, pero sugiere que el disco forma parte de la historia. La lista de procesos muestra updatedb (base de datos locate) y un agente endpoint haciendo trabajo.

Decisión: Si un proceso domina la CPU, inspecciónalo primero. Si la espera de I/O es alta (>15–20% sostenida), salta a las herramientas de I/O (Tareas 3–5).

Task 2: Check memory pressure and swap churn (free)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        11Gi       420Mi       1.2Gi       3.6Gi       3.1Gi
Swap:          2.0Gi       248Mi       1.8Gi

Qué significa: Poca “free” no es automáticamente mala; el campo importante es “available”. Si available es pequeño y el uso de swap sube rápidamente tras el arranque, estás ante presión de memoria.

Decisión: Si “available” está por debajo de ~10% de la RAM y el swap aumenta, deja de culpar a “aplicaciones de inicio” e identifica a los consumidores de memoria (Tarea 6) o reduce servicios.

Task 3: Find the top disk writers/readers (iotop)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 12.34 M/s | Total DISK WRITE: 48.91 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2345 be/4  root      0.00 B/s   35.12 M/s  0.00 %  12.45 %   updatedb.mlocate
 1988 be/4  root      1.20 M/s   10.50 M/s  0.00 %   8.90 %   falcon-sensor

Qué significa: Tienes un claro escritor principal. Un IO> alto significa que el hilo pasa tiempo esperando I/O.

Decisión: Si un trabajo programado (updatedb, indexador, escaneo antivirus) está golpeando los discos al iniciar sesión, reprograma o excluye directorios. Si es un agente, revisa su política y registros (Tareas 10–12).

Task 4: Confirm disk latency and queueing (iostat)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-21-generic (server) 	02/05/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.12    0.00    5.01   18.22    0.00   56.65

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         12.0    1024.0     0.0    0.0   25.10    85.3    210.0   45120.0     3.0    1.4   38.40   214.9   8.20   99.0

Qué significa: %util cerca de 99% y un await alto indican que el dispositivo está saturado. Incluso un NVMe “rápido” puede sufrir por escrituras pequeñas intensas o throttling por firmware/temperatura.

Decisión: Si el disco está saturado, el arranque limpio no lo solucionará mágicamente si el culpable está en el SO base (tormenta de journaling, errores de fs, swap). Identifica qué procesos generan I/O (Tarea 3) y revisa la salud del almacenamiento (Tarea 5).

Task 5: Check disk health and error counters (smartctl)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'critical_warning|media_errors|num_err_log_entries|temperature|percentage_used'
Critical Warning:                   0x00
Temperature:                       71 Celsius
Percentage Used:                   78%
Media and Data Integrity Errors:   12
Error Information Log Entries:     144

Qué significa: Un disco caliente con errores de medios/no nulos es una mala señal. “Percentage Used” cercano al fin de vida puede correlacionar con picos de latencia.

Decisión: Si los errores aumentan o el disco se sobrecalienta, trátalo como riesgo de hardware. El arranque limpio puede ayudar a aislar software, pero debes planear reemplazo y copias de seguridad ahora.

Task 6: Find the memory hog quickly (ps)

cr0x@server:~$ ps -eo pid,comm,rss,%mem --sort=-rss | head
  PID COMMAND           RSS %MEM
 4121 chrome          1854320 11.3
 1988 falcon-sensor    512300  3.1
 2770 tracker-miner    402112  2.4

Qué significa: El tamaño residente (RSS) muestra quién está ocupando memoria. Los navegadores siempre son sospechosos, pero a veces lo son porque otra cosa ralentizó el sistema y el navegador se acumuló.

Decisión: Si un agente o indexador es enorme justo después del arranque, desactívalo temporalmente en la fase de arranque limpio y confirma la mejora.

Task 7: Identify slow systemd units (systemd-analyze blame)

cr0x@server:~$ systemd-analyze blame | head -n 15
38.221s network-online.target
21.104s docker.service
12.880s snapd.service
10.512s systemd-journal-flush.service
 8.402s dev-sda2.device

Qué significa: Esto ordena las unidades por tiempo empleado. No es perfecto (existe paralelismo), pero es una excelente prueba de olfato.

Decisión: Si network-online.target es lento, sospecha de DHCP/DNS o de un servicio que espera “online” cuando no lo necesita. Si Docker/snapd son lentos, puedes estar pagando por imágenes, montajes o actualizaciones en segundo plano.

Task 8: See boot critical path (systemd-analyze critical-chain)

cr0x@server:~$ systemd-analyze critical-chain
graphical.target @1min 20.532s
└─multi-user.target @1min 20.532s
  └─docker.service @58.102s +21.104s
    └─network-online.target @36.900s +21.201s
      └─NetworkManager-wait-online.service @15.702s +21.190s
        └─NetworkManager.service @4.120s +11.550s
          └─dbus.service @4.090s

Qué significa: Muestra la cadena de dependencias y dónde se acumula el tiempo.

Decisión: Si un servicio wait-online está bloqueando el arranque, decide si realmente lo necesitas. Muchos servicios pueden iniciarse con la red “disponible después”. En escritorios, esperar a “online” suele ser autolesivo.

Task 9: List enabled services (systemctl)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled | head -n 25
UNIT FILE                                  STATE   PRESET
NetworkManager.service                     enabled enabled
docker.service                             enabled disabled
snapd.service                              enabled enabled
falcon-sensor.service                      enabled enabled
cups.service                               enabled enabled

Qué significa: Enabled significa que se iniciará en el arranque o cuando se dispare.

Decisión: Marca candidatos para el arranque limpio: agentes de terceros, motores de contenedores en portátiles, servicios de indexado, servicios de impresión en servidores, cualquier cosa que no sea esencial para el rol.

Task 10: Temporarily disable a service (safe and reversible)

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

Qué significa: El servicio no se iniciará automáticamente y se ha detenido ahora.

Decisión: Reinicia y mide. Si el arranque/post-login mejora, tienes un fuerte sospechoso. Si no cambia nada, vuelve a habilitar y sigue adelante.

Task 11: Mask a service that keeps coming back (hard stop)

cr0x@server:~$ sudo systemctl mask --now snapd.service
Created symlink /etc/systemd/system/snapd.service → /dev/null.

Qué significa: Enmascarar evita arranques manuales o por dependencias. Es más fuerte que deshabilitar.

Decisión: Usa el enmascaramiento cuando un servicio esté activado por socket o se dispare repetidamente. Documenta el cambio; enmascarar sorprende al tú del futuro.

Task 12: Read the logs for a specific boot (journalctl)

cr0x@server:~$ journalctl -b -p warning..alert --no-pager | tail -n 30
Feb 05 10:02:33 server kernel: nvme nvme0: I/O 17 QID 1 timeout, aborting
Feb 05 10:02:34 server systemd[1]: NetworkManager-wait-online.service: start operation timed out. Terminating.
Feb 05 10:02:34 server systemd[1]: Failed to start Network Manager Wait Online.

Qué significa: Timeouts de almacenamiento y timeouts de espera de red no son “aleatorios”. Son flechas rojas grandes.

Decisión: Timeouts NVMe: sospecha firmware/salud del disco/temporalidad térmica (Tarea 5), o rarezas de gestión de energía. Timeouts de red: elimina la dependencia del objetivo online, arregla DHCP/DNS o reduce el timeout.

Task 13: Verify what changed recently (package history)

cr0x@server:~$ grep -E " upgrade | install " /var/log/dpkg.log | tail -n 10
2026-02-04 18:22:11 upgrade linux-image-6.5.0-21-generic:amd64 6.5.0-20.20 6.5.0-21.21
2026-02-04 18:22:15 upgrade network-manager:amd64 1.44.2-1ubuntu1 1.44.2-1ubuntu2
2026-02-04 18:22:17 install falcon-sensor:amd64 7.12.0-1 7.12.0-1

Qué significa: Si el rendimiento se hundió “ayer”, esto te da candidatos sin confiar en la memoria, que es notoriamente poco fiable.

Decisión: Si se instaló un nuevo agente, súbelo al tope de la lista de sospechosos para el arranque limpio. Si se actualizó el kernel, considera probar la entrada de kernel previa para separar una regresión del kernel del espacio de usuario.

Task 14: Check user-level autostart (desktop agnostic)

cr0x@server:~$ ls -1 ~/.config/autostart 2>/dev/null | head
com.slack.Slack.desktop
dropbox.desktop
teams.desktop

Qué significa: Estas aplicaciones se inician tras el login y pueden dominar la percepción de “arranque lento”. También adoran actualizarse en el peor momento.

Decisión: Mueve elementos fuera de autostart (no borres todavía), luego reintrodúcelos por lotes.

Task 15: Verify background timers and cron-like jobs (systemd timers)

cr0x@server:~$ systemctl list-timers --all | head -n 20
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Thu 2026-02-05 10:30:00 UTC  12min left    Thu 2026-02-05 10:00:00 UTC  18min ago    updatedb.timer               updatedb.service
Thu 2026-02-05 11:00:00 UTC  42min left    Thu 2026-02-05 09:00:00 UTC  1h 18min ago snapd.refresh.timer          snapd.service

Qué significa: “Mi portátil es inutilizable tras el login” puede ser un timer que se dispara inmediatamente después del arranque.

Decisión: Reprograma timers pesados a horas de inactividad, o añade condiciones para que no se ejecuten justo tras el arranque cuando hay batería.

Task 16: See why a unit started (show dependencies)

cr0x@server:~$ systemctl show -p WantedBy,RequiredBy,After,Requires docker.service
WantedBy=multi-user.target
RequiredBy=
After=network-online.target containerd.service
Requires=containerd.service

Qué significa: Aprendes si una unidad está explícitamente habilitada, tirada por un objetivo, o requerida por otra cosa.

Decisión: Si una unidad es arrastrada por otra dependencia, deshabilitarla puede no ser suficiente; arregla la relación padre o ajusta wants/requires en archivos de override.

Broma #2: Lo único que arranca más rápido que un agente de inicio problemático es la reunión donde alguien pregunta por qué está instalado.

Tres micro-historias corporativas (cómo sale mal y bien)

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

El problema empezó como una queja estándar: “Los portátiles de ingeniería están lentos tras el despliegue del nuevo VPN”. El helpdesk hizo lo que hacen los helpdesks: reimaginó algunos sistemas, cambió docks, culpó al Wi‑Fi. Nada duró.

Un SRE finalmente lo trató como un incidente de producción: medir primero, luego aislar. Un arranque limpio (servicios mínimos, sin agentes de terceros) hizo que las máquinas se comportaran normalmente. Eso falsó al instante la suposición de que “la imagen del SO está inflada” o que “el hardware es viejo”. El problema estaba en los complementos.

Reintrodujeron servicios por lotes. La ralentización volvió cuando se inició un componente específico de “postura de red”. La suposición errónea había sido atribuir el cuello de botella al cliente VPN. No era así. El agente de postura hacía búsquedas DNS sincrónicas durante el login, bloqueando la pila de red hasta alcanzar un conjunto de endpoints internos—que eran inalcanzables fuera de la red.

La solución no fue heroica: ajustar el agente para que no bloquee el login en esas comprobaciones y acortar timeouts. La lección fue aburrida y brutal: asumir “la VPN está lenta” hizo perder días. El arranque limpio convirtió el problema en un solo paquete y un solo comportamiento de configuración.

Micro-historia 2: La optimización que salió mal

Un equipo de plataforma quería arranques más rápidos en servidores de laboratorio. Alguien observó que journald flush y las comprobaciones de sistema de archivos tardaban tiempo. “Optimizó” ajustando la persistencia de logs y relajando algunas comprobaciones de montaje. Los arranques parecían más rápidos—en los paneles.

Luego vino el incidente: fallos intermitentes de aplicaciones tras reinicio, sin causa obvia. El equipo tenía menos logs (porque no se persistían igual), y cuando un nodo tuvo un percance de almacenamiento, las comprobaciones atenuadas permitieron que subiera “bien” mientras su sistema de archivos estaba silenciosamente enfermo. La latencia subió, las descargas de Docker se colgaron y el on-call leía posos del té.

La técnica de arranque limpio ayudó de nuevo, pero de otra manera: incluso con servicios mínimos se vieron los picos de latencia de I/O. Eso apuntó fuera de los servicios de aplicación y hacia el almacenamiento y el comportamiento del SO base. Eventualmente correlacionaron los primeros mensajes de error con la ventana de arranque donde la “optimización” cambió el comportamiento de logs y montajes.

El rollback lo arregló. Reintrodujeron el trabajo de rendimiento correctamente: mantener comprobaciones de integridad, mantener logs útiles y centrarse en reducir esperas innecesarias por red-online y deshabilitar servicios no esenciales para ese rol de servidor. La moraleja: recortar segundos del arranque reduciendo la observabilidad es como quitar el paracaídas para ahorrar peso.

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

Un departamento financiero tenía una flota de escritorios con carga predictible: hojas de cálculo, pestañas del navegador y VPN ocasional. El equipo de TI tenía una costumbre que nunca ganó premios: mantenían una “configuración base de inicio” escrita para la imagen estándar—qué servicios estaban habilitados, qué aplicaciones autostart se permitían y qué timers se ejecutaban cuándo.

Un mes, los usuarios empezaron a reportar congelamientos justo después del login. El equipo de TI no entró en pánico. Compararon un host “malo” con la línea base. Surgió una única nueva entrada de autostart: un cliente de sincronización en la nube desplegado por otro grupo, configurado para iniciarse para cada usuario y escanear los directorios personales inmediatamente.

Hicieron arranque limpio deshabilitando autostarts de usuario y confirmaron que el sistema estaba sano. Luego reactivaron autostarts en dos lotes y reprodujeron el congelamiento con el cliente de sincronización solo. No tuvieron que discutir ni especular porque la lista base hizo visible el cambio.

La solución también fue aburrida: configurar inicio retrasado para el cliente de sincronización, añadir exclusiones para directorios grandes de build y limitar concurrencia. El día se salvó no por genialidad, sino por una línea base y un flujo de arranque limpio reproducible.

Errores comunes: síntoma → causa raíz → solución

Aquí es donde la mayoría de los equipos pierde tiempo. No porque el problema sea difícil, sino porque el método de depuración es descuidado.

1) Síntoma: “El arranque es lento” (pero solo después del login)

Causa raíz: aplicaciones de autostart a nivel de usuario, indexadores, clientes de sincronización o inicialización pesada del shell; el arranque en sí está bien.

Solución: aísla servicios de usuario y autostarts; mide tiempo hasta login vs tiempo hasta escritorio utilizable por separado. Usa la Tarea 14 y elimina selectivamente ítems de ~/.config/autostart. Reintrodúcelos por lotes.

2) Síntoma: pausa larga en “A start job is running…”

Causa raíz: unidad systemd esperando network-online, montaje faltante o cadena de dependencias con un timeout largo.

Solución: ejecuta systemd-analyze critical-chain (Tarea 8), luego elimina dependencias innecesarias en network-online.target o arregla el montaje. Considera reducir timeouts de wait-online en escritorios.

3) Síntoma: ventiladores giran, CPU “ocupada”, pero todo está lento

Causa raíz: saturación de I/O de disco causando espera de I/O en la CPU; a menudo un indexador, escaneo antivirus/EDR o tormenta de logging.

Solución: verifica con iostat (Tarea 4) y iotop (Tarea 3). Reprograma trabajos pesados (Tarea 15), ajusta políticas de agentes, añade exclusiones o arregla el problema subyacente del disco.

4) Síntoma: congelamientos aleatorios durante el arranque, errores en logs

Causa raíz: timeouts de almacenamiento, SSD inestable, problemas de controlador o throttling térmico.

Solución: comprueba SMART (Tarea 5) y logs del kernel (Tarea 12). Si hay errores, trátalo como fallo inminente: haz backups, planifica reemplazo, reduce carga y actualiza firmware si procede.

5) Síntoma: el arranque limpio sigue lento

Causa raíz: no es un problema de “app”; es el SO base, kernel, controlador, sistema de archivos o hardware.

Solución: prueba un kernel anterior, comprueba salud del disco, errores de sistema de archivos e inspecciona logs de arranque. El arranque limpio es un filtro; si no mejora nada, deja de buscar apps de usuario.

6) Síntoma: deshabilitas un servicio, pero vuelve

Causa raíz: activación por socket, activación por ruta, timers o un agente de gestión que lo vuelve a habilitar.

Solución: identifica triggers con systemctl list-timers (Tarea 15) y dependencias de unidades (Tarea 16). Enmascara temporalmente (Tarea 11) y coordina con la gestión del dispositivo.

7) Síntoma: el rendimiento está bien, luego empeora 2–10 minutos después del arranque

Causa raíz: timers que se disparan post-boot (updatedb, snap refresh, subida de telemetría) o agentes con inicio retrasado.

Solución: mira timers (Tarea 15) y logs con marcas temporales. Mueve tareas pesadas fuera de ventanas de login, especialmente en portátiles y VDI.

8) Síntoma: aplicaciones dependientes de red se cuelgan al iniciar

Causa raíz: latencia de DNS, conflictos de split-DNS de VPN, portal cautivo o configuración del resolvedor rota.

Solución: reduce la dependencia de la promesa “network online”; arregla la configuración del resolvedor. Valida que los trabajos de inicio usen timeouts y no bloqueen el objetivo de arranque.

Listas de verificación / plan paso a paso

Checklist A: El plan de bisección de arranque limpio (rápido y controlado)

1. Define la falla: escribe el tiempo de arranque y/o tiempo hasta escritorio utilizable.
2. Mide el recurso dominante: CPU, memoria, disco, red (Tareas 1–4).
3. Haz snapshot de lo habilitado: servicios, timers, autostarts de usuario (Tareas 9, 15, 14).
4. Elige un conjunto mínimo: conserva solo servicios requeridos para login y acceso remoto.
5. Deshabilita sospechosos en dos lotes: no uno por uno. Usa disable/mask con cuidado (Tareas 10–11).
6. Reinicia y mide: la misma medición cada vez.
7. Si mejora: vuelve a habilitar la mitad de los ítems deshabilitados (bisección) y repite.
8. Cuando se reproduce: aísla a una sola unidad/aplicación, y confirma alternando solo esa.
9. Arregla correctamente: configuración, programación, exclusiones o desinstalación con control de cambios.
10. Documenta y crea la línea base: registra qué se cambió y por qué.

Checklist B: Reglas de seguridad (evita outages autoinfligidos)

• No deshabilites el acceso remoto en un sistema remoto a menos que tengas acceso por consola.
• Prefiere disable antes que mask. Enmascarar es un martillo.
• Cambia un “lote” por reinicio. Si no, no podrás atribuir el efecto.
• Mantén una lista de rollback: qué deshabilitaste, en qué orden y cómo restaurarlo.

Checklist C: Si sospechas del almacenamiento (sesgo SRE/ingeniero de almacenamiento)

1. Busca espera de I/O en top y saturación en iostat.
2. Encuentra al infractor de I/O via iotop.
3. Comprueba SMART por errores/temperatura.
4. Si hay errores: deja de “tunear”, empieza a planear reemplazo y asegurar backups.
5. Si no hay errores: ajusta al infractor (ámbito de indexado, ajustes de agentes, volumen de logging), no todo el SO.

Preguntas frecuentes

1) ¿“Arranque limpio” es lo mismo que Modo Seguro?

No. El Modo Seguro suele cargar un conjunto deliberadamente restringido de controladores y servicios para recuperación. El arranque limpio es un arranque de diagnóstico que busca mantener el sistema usable mientras excluye componentes de terceros y no esenciales.

2) ¿Cómo sé si el problema es de driver/kernel frente a una app?

Si el problema persiste en un arranque mínimo (sin GUI, servicios mínimos) y sigues viendo timeouts de I/O, errores de kernel o picos de latencia consistentes, sospecha de driver/kernel/almacenamiento/hardware. Si el arranque mínimo está limpio, casi siempre es un servicio/agent/elemento de inicio.

3) ¿Cuál es la manera más rápida de encontrar qué enlentece el arranque en systemd?

systemd-analyze blame y systemd-analyze critical-chain. Blame muestra tiempo por unidad; critical-chain muestra las dependencias que afectan realmente la ruta de extremo a extremo.

4) ¿Por qué “network-online.target” causa tantos arranques lentos?

Porque “online” es una promesa más fuerte de lo que la mayoría del software necesita, y a menudo se implementa esperando DHCP, rutas y resolución DNS. Si alguna parte es lenta o está bloqueada (VPN, portal cautivo, DNS malo), pagas la tasa de timeout.

5) ¿Puedo hacer arranque limpio sin reiniciar?

A veces. Para lentitud post-login puedes detener servicios de usuario y apps de autostart sin reiniciar. Pero para medir la canalización real de arranque necesitas al menos un reinicio para validar causa y efecto.

6) ¿Qué pasa si mi gestión de dispositivos vuelve a habilitar servicios que desactivo?

Entonces estás depurando dos sistemas: el SO y la política de gestión. Enmascarar puede impedir temporalmente que una unidad arranque, pero coordina con quien sea dueño de la política; de lo contrario la “solución” se revertirá en silencio.

7) ¿Cómo hago arranque limpio de forma segura en un servidor remoto?

No deshabilites SSH o unidades de red salvo que tengas acceso out-of-band por consola. Prefiere deshabilitar solo servicios no centrales primero. Mantén un plan de rollback temporizado (como mínimo, una segunda sesión lista para revertir cambios).

8) ¿Cuál es un patrón común de “aplicación mala” en portátiles de desarrolladores?

Motores de contenedores, indexadores de archivos, clientes de sincronización y agentes de seguridad endpoint. El modo de fallo es carga de inicio por ráfagas: muchas operaciones de archivos pequeños y comprobaciones de red justo cuando el sistema está frío.

9) Si el culpable es un agente endpoint, ¿qué puedo hacer?

Normalmente: ajustar la política (excluir directorios de build, node_modules, caches), modificar horarios de escaneo y reducir logging excesivo. Desinstalar software de seguridad sin aprobación es una decisión que limita la carrera.

10) ¿Cómo evito que esto vuelva a ocurrir?

Mantén una lista base de servicios habilitados, timers y autostarts por rol de máquina, y revisa cambios como parte del despliegue de software. La práctica “aburrida pero correcta” escala.

Conclusión: siguientes pasos que perduran

El arranque limpio es un bisturí. Úsalo como tal. Tu objetivo no es dejar un sistema permanentemente incapacitado; tu objetivo es aislar al culpable con mínimo drama y máxima confianza.

1. Ejecuta el guion de diagnóstico rápido y decide qué recurso domina.
2. Haz un arranque limpio controlado (objetivos mínimos + sospechosos deshabilitados).
3. Bisecciona en lugar de deshabilitar uno por uno.
4. Arregla la causa raíz: timeouts, programación, exclusiones, cadenas de dependencias o almacenamiento fallando—no superstición.
5. Escribe una línea base para tu entorno para que la próxima regresión sea un diff rápido, no una caza de fantasmas de una semana.

Si haces esto bien, aislarás la aplicación problemática en menos de 10 minutos. Si lo haces mal, aún aislarás algo—usualmente tu credibilidad.