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