Ya habréis notado que desde ayer systemd ha pasado a ser el sistema de arranque
por defecto de Debian Jessie (y previamente de Sid). Si no lo habéis notado es
que, o bien estábais ya usando systemd, o todavía no habéis dist-upgradeado
los recientes paquetes de systemd que actualizan las versiones 204 a las 208.
Las nuevas versiones de los paquetes de systemd tienen conflictos con
sysvinit-core, con lo que no cabe postponer más el salto: hay que abandonar
definitivamente el tradicional arranque System V. La alternativa es
renunciar a "unos cuantos paquetes" que dependen de servicios proporcionados
por systemd, lo que puede resultar desde una "pequeña molestia" a
que os intente eliminar media distro, según qué tengáis instalado.
Una de las ventajas de usar systemd que siempre se cita es que el arranque es
más rápido. Mi arranque rondaba los 16 segundos con sysvinit según lo último
medido en mi entrada sobre los retrasos en el arranque debidos a
avahi. He intentado utilizar un servicio que tiene systemd llamado
systemd-bootchar para replicar las mediciones que hice allí con
bootchart2, pero no he sido capaz. Por alguna razón que todavía no he conseguido
averiguar los SVG no se generan en el directorio /run/log ni en el
journal. Así que he tenido que usar otra de las herramientas que trae systemd
llamada systemd-analyze. Esta herramienta puede ser invocada de distintas
formas para obtener diversos datos, incluyendo systemd-analyze
plot que genera una gráfica en formato SVG (os sugiero hacer Ver imagen
con el navegador para ver la gráfica completa):
Según esta herramienta los arranques rondan ahora los 13 segundos. Bien, no se
puede decir que no sea una mejora, aunque es una mejora muy modesta en mi
opinión. Por sí sola no justifica el cambio de sistema de init (aunque YMMV).
Por supuesto soy consciente que systemd ofrece muchas otras ventajas aparte de
la velocidad de arranque.
Más interesantes me han parecido los resultados de systemd-analyze blame (que
devuelve el tiempo empleado en la activación de cada proceso, ordenados de mayor
a menor) y systemd-analyze critical-chain (que nos muestra el camino que
retrasa más el arranque). Ambos nos sirven para encontrar cuellos de botella en
nuestro arranque:
$ systemd-analyze blame
3.307s systemd-fsck-root.service
2.999s keyboard-setup.service
2.578s exim4.service
2.221s lightdm.service
1.891s systemd-logind.service
1.591s upower.service
1.500s rsyslog.service
1.239s console-kit-log-system-start.service
1.146s networking.service
954ms lm-sensors.service
909ms bootlogs.service
665ms systemd-fsck@dev-disk-by\x2duuid-xxxxxxx
622ms hdparm.service
600ms colord.service
536ms systemd-modules-load.service
456ms sys-kernel-debug.mount
445ms minissdpd.service
417ms motd.service
400ms dev-mqueue.mount
399ms dev-hugepages.mount
389ms systemd-udev-trigger.service
...
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @9.989s
└─multi-user.target @9.989s
└─fetchmail.service @9.793s +195ms
└─exim4.service @7.214s +2.578s
└─nss-lookup.target @7.214s
└─bind9.service @7.214s
└─basic.target @7.213s
└─timers.target @7.206s
└─systemd-tmpfiles-clean.timer @7.206s
└─sysinit.target @7.152s
└─nfs-common.service @6.926s +225ms
└─rpcbind.target @6.926s
└─rpcbind.service @6.805s +120ms
└─network-online.target @6.804s
└─network.target @6.804s
└─networking.service @5.657s +1.146s
└─local-fs.target @5.657s
└─home.mount @5.570s +86ms
└─systemd-fsck@dev-disk-by\x2duuid-xxxxxxx
└─dev-disk-by\x2duuid-xxxxxxx
Estos datos por ejemplo están indicando retrasos por un lado en
networking.service (que podría corresponder con la demora ya conocida del
driver de red e1000e) y por otro en el arranque de servidor de correo exim, que
aquí le cuesta más de 2 segundos y medio y en algunos casos más de 3 segundos.
Ambos son puntos con potencial para ser optimizados y reducir el tiempo de
arranque global, mientras que por ejemplo keyboard-setup.service, aunque me
parece que también sea un tiempo disparatado para configurar el teclado, al
ejecutarse en paralelo y terminar mucho antes que esta otra ruta, cualquier
mejora ahí no se va a notar en el proceso global de arranque (y por lo tanto
ahora mismo sería una pérdida de tiempo tratar de mejorarlo).
:wq