Tarda demasiado tiempo en arrancar el entorno gráfico
GNOME 3. Desde que aparece el menú de opciones de
Grub2 hasta que aparece el login screen pasan más de dos minutos.
Para comprobar cuánto tiempo consume el proceso de arranque utilizamos el comando:
# systemd-analyze
que devuelve el resultado:
Startup finished in 1.461s (kernel) + 1.592s (initrd) + 2min 10.568s (userspace) = 2min 13.622s
graphical.target reached after 2min 5.083s in userspace
Para saber que proceso es responsable del arranque lento, se puede ejecutar:
# systemd-analyze blame
y muestra el resultado siguiente:
2min 1.010s lvm2-monitor.service
2min 493ms systemd-udev-settle.service
6.875s NetworkManager-wait-online.service
1.551s dmraid-activation.service
1.374s plymouth-quit-wait.service
793ms udisks2.service
735ms fwupd.service
654ms dkms.service
650ms initrd-switch-root.service
631ms firewalld.service
508ms dev-md126p1.device
455ms dracut-pre-pivot.service
451ms upower.service
350ms dnf-makecache.service
340ms systemd-logind.service
228ms libvirtd.service
181ms accounts-daemon.service
149ms dracut-initqueue.service
134ms dracut-pre-trigger.service
117ms user@1000.service
115ms systemd-udev-trigger.service
114ms sysroot.mount
108ms polkit.service
106ms user@42.service
96ms home.mount
96ms geoclue.service
Parece que la mayor parte del retraso proviene del proceso
lvm2-monitor.service. Este proceso se encarga de monitorizar el uso del LVM.
Si no utilizas LVM se puede deshabilitar sin problemas. Para identificar que el servicio
lvm2-monitor está habilitado y en uso puedes usar el comando:
# systemctl status lvm2-monitor
Este comando devuelve la siguiente información si el servicio está activado:
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2018-08-06 22:12:47 CEST; 41min ago
Process: 710 ExecStart=/usr/sbin/lvm vgchange --monitor y --ignoreskippedcluster (code=exited, status=0/SUCCESS)
Main PID: 710 (code=exited, status=0/SUCCESS)
En mi caso, el servicio
systemd-udev-settle también causa buena parte del retraso en el arranque. Para comprobar su estado ejecuto:
# systemctl status systemd-udev-settle.service
y devuelve la siguiente información:
● systemd-udev-settle.service - udev Wait for Complete Device Initialization
Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2018-08-06 22:12:46 CEST; 41min ago
Docs: man:udev(7)
man:systemd-udevd.service(8)
Process: 759 ExecStart=/usr/bin/udevadm settle (code=exited, status=1/FAILURE)
Main PID: 759 (code=exited, status=1/FAILURE)
Aug 06 22:10:46 systemd[1]: Starting udev Wait for Complete Device Initialization...
Aug 06 22:12:46 systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE
Aug 06 22:12:46 systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'.
Aug 06 22:12:46 systemd[1]: Failed to start udev Wait for Complete Device Initialization.
Desactivo ambos servicios con los comandos:
# systemctl mask systemd-udev-settle.service
Created symlink /etc/systemd/system/systemd-udev-settle.service → /dev/null.
systemctl mask lvm2-activation-net.service
#systemctl mask lvm2-activation-net.service
Unit lvm2-activation-net.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/lvm2-activation-net.service → /dev/null.
Y ahora reiniciamos el sistema y comprobamos nuevamente los tiempos de arranque.
# systemd-analyze
Startup finished in 1.465s (kernel) + 1.602s (initrd) + 10.034s (userspace) = 13.102s
graphical.target reached after 4.211s in userspace
Y para determinar el proceso que más tarda en responder hacemos:
# systemd-analyze blame
Y ahora devuelve el siguiente resultado:
21.856s dnf-makecache.service
6.830s NetworkManager-wait-online.service
1.160s udisks2.service
996ms plymouth-quit-wait.service
741ms fwupd.service
652ms initrd-switch-root.service
564ms dkms.service
560ms firewalld.service
536ms dev-md126p1.device
442ms dracut-pre-pivot.service
390ms home.mount
376ms systemd-logind.service
306ms upower.service
264ms systemd-fsck@dev-disk-by\x2duuid-1576514b\x2d25a2\x2d446e\x2d867f\x2de15bef848cff.service
171ms accounts-daemon.service
163ms dracut-initqueue.service
155ms libvirtd.service
138ms dracut-pre-trigger.service
137ms auditd.service
119ms user@1000.service
117ms systemd-journal-flush.service
Aquí hay una buena explicación de porqué se puede deshabilitar el servicio
udev-settle sin que el sistema lo note.
