Ich möchte euch einen Lösungsvorschlag präsentieren. Ich hab in meinem Laptop eine SSD, und mein Bootvorgang benötigte ab nach dem Laden des Kernels immer noch so um die 10-12 Sekunden. NetworkManager.service, ModemManager.service zeigten sehr sehr lange Zeiten zum starten in der Ausgabe von
Code: Alles auswählen
systemd-analyze plog > /home/$USER/bootchart.svg
Ich starte bei mir schon beim Booten dropbox und minidlna.
Es gibt dropbox.target und minidlna.target, welche ein "WantedBy=network-online.target" in der [Install]-Section haben.
Diese beiden Targets wiederum starten dropbox@USER1.service, dropbox@USER2.service und auch minidlna@S1.service, minidlna@S2.service...
Der Start von dropbox benötigt schon mal 1,5 bis 2,5 Sekunden, minidlna ist auch durch das Parsen der Verzeichnisse nicht besonders schnell beim Start. In Summe ergibt das schon mal eine Startverzögerung von 4-5 oder mehr Sekunden, da über die Targets und die Abhängigkeit mit network-online.target das Beenden des Startvorganges von NetworkManager verzögert wird.
Exkurs:
Der Grund, warum ich Dropbox schon beim Booten für die einzelnen User starte ist folgender, ich habe öfter einmal größere Mengen an Fotos/Videos die ich in die Dropbox von meinem Smartphone sichere. Und damit ich sie, wenn ich heimkomme schon am Laptop zum Sichten habe, lade ich sie auch ohne meinem Userlogin schon runter.
Jetzt habe ich lange überlegt, wie ich die Verzögerung des Boots durch diese Dienste wegbekommen kann, da ich immer wieder von Bootzeiten von 2-3 Sekunden gelesen habe...
Ich kam auf die Idee dropbox.target und minidlna.target nicht mit WantedBy= an multi-user.target zu hängen, sondern einen Timer mit Target zu erstellen, an dessen Target ich dann die beiden Targets hänge:
Dieser Timer wird gestartet, wenn network-online.target gestartet wird.
Code: Alles auswählen
# cat timer-online.timer
[Unit]
PartOf=network-online.target
[Timer]
OnActiveSec=20s
Unit=timer-online.target
[Install]
WantedBy=network-online.targetCode: Alles auswählen
# systemctl cat timer-online.target
# /lib/systemd/system/timer-online.target
[Unit]
Description=Target after online
StopWhenUnneeded=yesDies ruft dann dropbox.target und minidlna.target auf, die wiederum eben die eigentlichen Services aufrufen, die zum Start länger benötigen.
Damit sieht dann die critical-chain so aus
# 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.
Code: Alles auswählen
graphical.target @2.703s
└─upower.service @1.815s +887ms
└─basic.target @1.812s
└─sockets.target @1.812s
└─uuidd.socket @1.812s
└─sysinit.target @1.809s
└─systemd-timesyncd.service @1.586s +222ms
└─systemd-tmpfiles-setup.service @1.569s +10ms
└─local-fs.target @1.568s
└─var-spool-dovecot.mount @1.484s +84ms
└─var-spool.mount @1.072s +401ms
└─dev-disk-by\x2duuid-9081c6de\x2d4a5a\x2d4b85\x2dac42\x2df3853e26c048.device @1.071sFür NetworkManager ist nicht der Abschluss des Bootens von dropbox@.service interessant, sondern ob der Timer erfolgreich gestartet wurde. Dieser Start geht in wenigen Millisekunden vonstatten und NM kann weitermachen.
Da es unerheblich ist, ob die Dropbox sofort nach dem Login zur Verfügung steht, oder ein paar Sekunden später, ebenso minidlna, kann ich den Start dieser Services ruhig vom eigentlichen Boot-Vorgang abkoppeln und so den graphischen Login-Manager schneller zur Verfügung haben.
Ich liebe so Spielereien mit systemd.
lg scientific
