# 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.
