SOLUCIÓN A: “A start job is running for…” el arranque que se queda esperando
Prendés la compu, Linux arranca y de golpe se frena en una pantalla con un mensaje parecido a «A start job is running for /dev/disk/by-uuid/…» y un contador que dice (1min 30s / no limit). Pasa un minuto, pasa un minuto y medio, y recién ahí sigue. No es un cuelgue definitivo, pero te hace perder tiempo en cada arranque, y la sensación es que algo está roto.
La buena noticia es que el mensaje te está diciendo exactamente qué está esperando systemd. Vamos a ver cómo leerlo, cómo encontrar al culpable y cómo evitar que se repita.
¿Qué significa el mensaje?
Durante el arranque, systemd lanza «trabajos» (jobs): montar un disco, activar la swap, levantar la red, iniciar un servicio. «A start job is running for…» quiere decir que uno de esos trabajos todavía no terminó y systemd lo está esperando antes de seguir.
El tiempo de espera por defecto es de 90 segundos, y de ahí sale el famoso minuto y medio. Si el trabajo no termina en ese plazo, systemd lo da por fallido y continúa con el arranque. Por eso el sistema «revive» solo pasado ese tiempo, y por eso el mensaje es una pista: lo que viene después de «for» es lo que está trabado.
Un disco o partición que ya no existe pero sigue en /etc/fstab (un disco externo, un pendrive, una partición borrada).
- Una swap con un UUID viejo, típico después de reinstalar o reparticionar: el sistema busca una swap que ya no está.
- Una referencia de hibernación (resume) desactualizada, que apunta a una partición swap que cambió de UUID.
- NetworkManager-wait-online.service, que espera a que haya red antes de seguir (frecuente con Wi-Fi o con cables desconectados).
- Un servicio propio o de terceros que tarda demasiado en iniciar o quedó mal configurado.
- Un disco con problemas de hardware que tarda en responder.
Solución paso a paso
1. Leer qué está esperando
Si el mensaje pasa muy rápido o no lo llegás a ver, durante el arranque podés apretar Esc para salir de la pantalla de carga y ver los mensajes en modo texto. Lo importante es anotar qué aparece después de «for».
Una vez que el sistema arrancó, también podés confirmarlo con los logs del arranque actual:
journalctl -b -p errEste comando muestra solo los mensajes de error del arranque actual. Si buscás algo más puntual, esta variante filtra por timeouts:
journalctl -b | grep -i "timed out"2. Ver qué servicio tarda más
Para medir cuánto tardó cada unidad en arrancar, usá:
systemd-analyze blameLa lista viene ordenada de mayor a menor tiempo. Si hay una unidad con 1 min 30 s, ya tenés a la sospechosa. Para ver la cadena de dependencias que más retrasó el arranque:
systemd-analyze critical-chain3. Si lo que espera es un disco o una swap: revisar fstab
Primero mirá qué dispositivos existen realmente en tu equipo y cuáles son sus UUID:
lsblk -fDespués compará esos UUID con los que figuran en /etc/fstab:
cat /etc/fstabSi hay una línea con un UUID que no aparece en la salida de lsblk -f, ahí está el problema. Antes de tocar nada, hacé una copia de seguridad:
sudo cp /etc/fstab /etc/fstab.bakDespués abrí el archivo con tu editor:
sudo nano /etc/fstabLa opción menos invasiva no es borrar la línea, sino indicarle a systemd que ese montaje no es indispensable y que no espere de más. Agregá nofail y un timeout corto en las opciones de esa línea:
UUID=xxxx-xxxx /mnt/datos ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2Con nofail, si el disco no está, el arranque sigue sin quejarse. Con x-systemd.device-timeout=10s, systemd espera 10 segundos en vez de 90. Si el disco ya no existe y no lo vas a volver a usar, comentá la línea anteponiendo #.
Para comprobar que el archivo quedó bien escrito, sin reiniciar:
sudo findmnt --verifyEste comando revisa la sintaxis y las referencias de /etc/fstab y te avisa si algo no cierra.
4. Si lo que espera es la swap o el «resume»
Si el mensaje menciona un /dev/disk/by-uuid/... que no coincide con ningún UUID de lsblk -f, puede ser una swap vieja en /etc/fstab (se corrige igual que en el paso anterior) o una referencia de hibernación desactualizada. En Debian, Ubuntu y Linux Mint esa referencia suele estar acá:
cat /etc/initramfs-tools/conf.d/resumeSi el archivo existe y el UUID que aparece en RESUME=UUID=... no coincide con el de tu swap actual, corregilo (o dejá la línea comentada si no usás hibernación) y regenerá el initramfs:
sudo update-initramfs -u5. Si lo que espera es la red
Cuando el culpable en systemd-analyze blame es NetworkManager-wait-online.service, significa que el sistema está esperando a tener conexión antes de seguir. Si es una notebook o una PC de escritorio que no necesita red para arrancar, podés desactivar ese servicio de espera:
sudo systemctl disable NetworkManager-wait-online.serviceEsto no desactiva la red ni NetworkManager, solo quita la espera del arranque. Si más adelante lo necesitás, se revierte con:
sudo systemctl enable NetworkManager-wait-online.service6. Si es otro servicio
Con el nombre exacto de la unidad que viste en systemd-analyze blame, revisá su estado y su log:
systemctl status nombre-del-servicio.service
journalctl -u nombre-del-servicio.service -bAhí vas a ver por qué tarda: una dependencia que no responde, un archivo de configuración con errores, un recurso remoto que no está disponible.
7. Comprobar que funcionó
Reiniciá y fijate si desapareció la espera. Después podés medir el arranque completo:
systemd-analyzeCompará el tiempo total con el de antes. Si bajó claramente, el problema estaba resuelto.
Solución gráfica
Si preferís no pasar por la terminal para identificar el disco, la aplicación Discos (GNOME Disks) en Ubuntu y Linux Mint te muestra todas las unidades y particiones del equipo. Seleccionás cada una y en la información de la partición ves su UUID, que es justamente lo que necesitás comparar con /etc/fstab. Sirve para confirmar rápido si el disco que está esperando systemd existe o no.
Casos especiales
Discos externos y pendrives en fstab: si dejaste un disco USB con una línea fija en /etc/fstab, el sistema va a esperarlo cada vez que arranque sin él conectado. Agregar nofail es casi obligatorio en estos casos.
Servidores y discos de red: con NFS o CIFS, el mismo mensaje aparece cuando el servidor remoto no responde. Ahí la causa está del lado del servidor o de la red, y nofail con un timeout corto evita que el cliente se quede esperando.
Raspberry Pi: si arranca desde una tarjeta SD o un SSD USB y falta un dispositivo secundario en fstab, el comportamiento es el mismo y se resuelve igual.
Qué no hacer
- No borrar líneas de
/etc/fstabsin hacer antes una copia o comentarlas, porque un error ahí puede impedir que el sistema arranque. - No desactivar servicios a ciegas para «ganar tiempo» sin saber qué hacen.
- No bajar el timeout global de systemd para todo el sistema si el problema es un solo dispositivo; es mejor ajustar solamente esa línea.
- No asumir que el disco está roto solo porque el arranque tarda: casi siempre es una referencia vieja y no una falla de hardware.
Conclusión
«A start job is running for…» es systemd esperando algo que no llega: un disco que ya no está, una swap con otro UUID, la red o un servicio lento. Con systemd-analyze blame y journalctl -b -p err identificás al culpable en minutos, y con nofail y un timeout corto en /etc/fstab evitás que vuelva a frenarte el arranque. Si después de corregirlo el mensaje sigue apareciendo con un disco que sí existe, ahí conviene revisar el estado de la unidad y sus logs antes de sospechar del hardware.
