Después de eliminar la mayoría de los servicios que no necesito, todavía me toma unos 28 segundos arrancar, tomar una foto y cerrar. Me gustaría bajar esto aún más, e hice un systemd-analyze blamey obtuve lo siguiente:

7.476s disableusb.service
1.736s keyboard-setup.service
958ms kbd.service
789ms systemd-fsck-root.service
737ms systemd-setup-dgram-qlen.service
722ms fake-hwclock.service
580ms kmod-static-nodes.service
565ms console-setup.service
534ms dev-mqueue.mount
518ms systemd-udev-trigger.service
498ms networking.service
489ms raspi-config.service
449ms hdparm.service
444ms systemd-journal-flush.service
376ms systemd-tmpfiles-setup.service
375ms dhcpcd.service
345ms systemd-logind.service
332ms ntp.service
317ms systemd-modules-load.service
281ms tmp.mount
272ms triggerhappy.service
269ms sys-kernel-debug.mount
265ms [email protected]
223ms rsyslog.service
221ms sys-kernel-config.mount
212ms systemd-tmpfiles-setup-dev.service
200ms systemd-remount-fs.service
198ms systemd-sysctl.service
184ms boot.mount
173ms systemd-random-seed.service
168ms rc-local.service
167ms [email protected]
165ms var-log.mount
141ms udev-finish.service
130ms sys-fs-fuse-connections.mount
111ms systemd-user-sessions.service
94ms systemd-update-utmp.service
94ms alsa-restore.service
93ms systemd-update-utmp-runlevel.service
77ms systemd-udevd.service
55ms takepicture.service

disableusb.servicees mío, y a diferencia de lo que el nombre implica, también hace otras cosas. Dudo que pueda mejorar el tiempo allí.

Mi sistema se ejecuta sin cabeza, por serie. Solo necesito redes a través de wifi (wifi no se inicia porque desactivo la alimentación del usb, pero a veces no la desactivo, para que pueda iniciarse).

Al mirar esta lista, veo cosas como: 1.736s keyboard-setup.servicey 958ms kbd.service. Tardan casi 3 segundos. ¿Los necesito si no estoy usando un teclado? Si no, ¿cómo los desactivo?

¿Qué más puedo desactivar de forma segura desde aquí?

Ok, hay algo realmente extraño yendo aquí. Desactivé algunos servicios más, y todavía lleva tanto tiempo en total, solo que ahora algunos servicios que tomaron menos tiempo antes tomaron mucho más tiempo ...

7.468s disableusb.service
1.676s console-setup.service
768ms systemd-logind.service
768ms systemd-fsck-root.service
726ms systemd-setup-dgram-qlen.service
714ms fake-hwclock.service
689ms networking.service
530ms systemd-journal-flush.service
524ms systemd-udev-trigger.service
509ms dev-mqueue.mount
509ms ntp.service
508ms kmod-static-nodes.service
439ms dhcpcd.service
334ms systemd-random-seed.service
331ms hdparm.service
318ms systemd-modules-load.service
281ms systemd-tmpfiles-setup.service
279ms [email protected]
279ms rsyslog.service
269ms systemd-remount-fs.service
265ms sys-kernel-config.mount
254ms systemd-tmpfiles-setup-dev.service
250ms systemd-sysctl.service
238ms rc-local.service
234ms systemd-udevd.service
232ms sys-kernel-debug.mount
224ms [email protected]
187ms tmp.mount
176ms sys-fs-fuse-connections.mount
175ms var-log.mount
133ms systemd-update-utmp.service
122ms systemd-update-utmp-runlevel.service
122ms systemd-user-sessions.service
119ms alsa-restore.service
91ms boot.mount
88ms udev-finish.service
76ms takepicture.service

Archivo de servicio: (no tengo idea de por qué la sintaxis del código no funciona)

[Unit]
Description=Disable USB power
Before=networking.service
After=local-fs.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/sbin/usb_down

[Install]

Aquí está la trama: http://www.eternal-lands.com/plot.svg

7.476s disableusb.service

Esto implica que está ejecutando algo en primer plano porque no es persistente, por lo que siente que no tiene sentido ponerlo en segundo plano. Sin embargo, si lleva tanto tiempo hacer lo suyo, tal vez debería bifurcarlo en segundo plano tan pronto como comience.

El problema aquí es simplemente que es más probable que beneficie su tiempo de arranque que dejarlo en primer plano, aunque puede no hacer ninguna diferencia de ninguna manera. Sin embargo, si algo más depende de que se complete (en lugar de simplemente completar con éxito la inicialización, que es más aplicable a un servicio persistente), entonces debe dejarlo como.

Veo cosas como: 1.736s keyboard-setup.service y 958ms kbd.service. Tardan casi 3 segundos.

Nunca lo he investigado porque no me importa mucho, pero creo que hay algo mal en la forma en que se maneja la "configuración del teclado" en Raspbian. Lo he visto funcionar 90 segundos antes de ser asesinado por systemd.

¿Los necesito si no estoy usando un teclado? Si no, ¿cómo los desactivo?

Supongo que no, pero esto puede crear una molestia para usted si de repente necesita un teclado ... o puede que no haga ninguna diferencia, parte de mi sospecha es que en realidad no está logrando nada, ya que el "teclado setup "es algo que es una configuración estática y se puede cambiar manualmente según sea necesario.

Para desactivar un servicio, sudo systemd disable ....

raspi-config.service

Es extraño que todavía esté allí, ya que se supone que se deshabilitará después de ejecutarse, pero eso podría no suceder si lo ignora. Eso podría estar relacionado con lo del teclado. Si es posible, debe enchufar un monitor y ver si aparece después del arranque. En cualquier caso, esto es algo más que también podría deshabilitar.

Aquí está la trama: http://www.eternal-lands.com/plot.svg

Creo que deberías hacer disableusb.service After=sysinit.target.

Mirando el gráfico, parece claro que la desactivación en console-setup.servicerealidad no acelerará nada de todos modos. Como puede ver, networking.serviceestá esperando hasta que se disableusb.servicecomplete, por lo que un tiempo de carga de 1.6 segundos para console-setup.serviceejecutar en paralelo no afectará en absoluto el tiempo de arranque general.

Hay una idea en la programación de una ruta crítica que, cuando se retrasa cualquier actividad en esta ruta, causa retrasos en todo el proyecto. Las otras actividades tienen "flotación", es decir, no son críticas y pueden retrasarse sin afectar el tiempo final de finalización.

Es esta ruta crítica la que debe ahorrar tiempo, no las actividades no críticas. systemd-analyze critical-chainle ayudará a identificar las actividades críticas, aunque puede detectarlas en la trama. Cualquier ganancia marginal disableusb.serviceayudaría significativamente a su tiempo de arranque.

También podría ayudar entender por qué sus servicios tardan tanto. Para esto, Bootchart2 podría ser útil. Se puede instalar con:

apt-get install systemd-bootchart

Para habilitarlo realmente, edite /boot/cmdline.txty configure:

init=/lib/systemd/systemd-bootchart

Una vez completado el arranque, encontrará el gráfico guardado en /run/logun archivo SVG. Luego, vuelva init=...a su configuración inicial (o elimínelo si no estaba allí antes).

Consulte también la páginasystemd-bootchart del manual para .

Estoy ejecutando un raspberrypi Zero sin cabeza y podría afeitarme unos segundos así:

Systemd

# Don't start the Light Display Manager on headless
sudo systemctl disable lightdm.service

# In a headless environment you don't need the keyboard setup.
sudo systemctl disable keyboard-setup.service

# Checks if the country is set in the WIFI config. This is likely a regulatory precaution.
sudo systemctl disable wifi-country.service

# Unless you have an external joystick or something that uses `/dev/input/`
sudo systemctl disable triggerhappy.service 

# I read that the swap file actually slows the PI down and decreases SD card lifetime. 
sudo systemctl disable dphys-swapfile.service

# Disable Bluetooth unless you need it
sudo systemctl disable hciuart.service

# Unless you have a hardware button to disable the WIFI you won't need this
sudo systemctl mask systemd-rfkill.service # disabling won't work


# Open GL should be obsolete on a headless machine
sudo systemctl disable gldriver-test.service

# Only disable this one if you're not using `/etc/rc.local`
sudo systemctl mask rc-local

# You might to re-enable this service when making changes using `sudo raspi-config`
sudo systemctl disable raspi-config.service

Tenga en cuenta que systemd-analyzegenera el tiempo de arranque:

Startup finished in 1.532s (kernel) + 20.862s (userspace) = 22.395s

Salida mínima de arranque

En boot/cmdline.txtcambio tty1a tty3y añadir loglevel=3 quiet logo.nologoal final después derootwait

Esto me ahorró otro segundo.

Misceláneos

Este chico logra un arranque de raspberrypi de 3 segundos: https://www.samplerbox.org/article/fastbootrpi

Este es un buen blog con algunos pasos para reducir el tiempo de arranque: http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry-pi.html

DougieLawson explica algunos de los servicios de raspberrpi https://www.raspberrypi.org/forums/viewtopic.php?t=195692

Tutorial en profundidad como PDF