Booten beschleunigen mit systemd

[scientific]

Hi Leute!

Wie ich schon im Beitrag über colord angemerkt habe, beschäftige ich mich gerade mit der Bootzeit meines Laptops. Dabei fiel mir auf, dass unter Debian noch sehr viele systemV-Startskripte mittels systemd.generator eingebunden werden. Durch die Socket-Activation kann man hier aber manches beschleunigen durch Parallelisierung, was offenbar viele Debian-Maintainer noch nicht umgesetzt haben (keine Kritik, nur eine Feststellung!!! Ist ja auch eine Mörderarbeit, alle Bootskripte auf systemd-units umzustellen!)

Jetzt habe ich manuelle einige Abhängigkeiten von den service-units auf socket-units "umgehängt". Z.B. cups oder avahi betreffend. Was auch meine bootzeit von 16-26 Sekunden für das Userland auf 5-6 Sekunden verkürzt hat. Ich bin beeindruckt. Allerdings ist im systemd-bootchart zuvor ein Block "kernel" mit 10sec vermerkt. Wird das ab dem Laden des Kernels in grub gemessen? Und kann man diese Zeit noch verkürzen? Bringt hier ein "schlankerer, ans System angepasster" Kernel wirklich noch viel Zeitersparnis?

Was mir noch aufgefallen ist, avahi-daemon.service ist mittels alias auch gleichzeitig avahi-daemon.socket und braucht ~1,4 Sekunden zum starten, wovon wiederum einige Dienste abhängig sind. Und 1,4Sekunden ist bei 5 Sekunden Startzeit mehr als ein Viertel der Zeit... Kann man das ev. noch anders lösen? Also wirklich ein "richtiges" Socket-File für avahi anlegen... Wenn ja, wie?

Dann fiel mir noch auf, dass rc-local.service fast 4 Sekunden benötigte um gestartet zu werden. Dabei ist in /etc/rc.local nichts drinnen... hab es jetzt einmal maskiert (also auf /dev/null gemapped), was ich aber nicht günstig finde... sollte einmal etwas in rc.local rein und ich hab vergessen, dass das maskiert ist, gibts wieder Katzenjammer... Bzw... durch die laufende Umstellung der Initskripte auf systemd-units wird über kurz oder lang rc-local sowieso überflüssig... oder?

Soweit so gut... ich hoffe spannende Erfahrungen und Antworten zu bekommen und freue mich auf eine nette Diskussion.

lg scientific

[KP97]

In meinem Sid sieht es so aus:

root@SID:/home/MB# systemd-analyze blame
907ms boottime-kmap.service
539ms dev-hugepages.mount
506ms sys-kernel-debug.mount
486ms kmod-static-nodes.service
435ms systemd-remount-fs.service
432ms systemd-udev-trigger.service
428ms alsa-restore.service
410ms systemd-logind.service
392ms systemd-modules-load.service
379ms systemd-localed.service
371ms systemd-hostnamed.service
240ms systemd-networkd.service
208ms systemd-udevd.service
163ms systemd-tmpfiles-setup-dev.service
147ms media-Test.mount
122ms systemd-journal-flush.service
119ms systemd-random-seed.service
113ms sys-kernel-config.mount
106ms systemd-tmpfiles-setup.service
99ms systemd-sysctl.service
59ms systemd-user-sessions.service
34ms systemd-update-utmp.service
17ms rc-local.service
7ms udev-finish.service
4ms systemd-update-utmp-runlevel.service
root@SID:/home/MB# systemd-analyze
Startup finished in 1.975s (kernel) + 3.692s (userspace) = 5.668s

Ich habe rigoros den kompletten Inhalt von /etc/init.d entsorgt und lasse alles über systemd regeln, also
CUPS, Netzwerk mit DHCP, Autologin ohne Displaymanager. Es läuft ein eigener Kernel, aber kein policykit, kein consolekit, kein avahi.
Alles funktioniert tadellos. Ich hatte vorher mit den Scripten immer das Gefühl, daß da einiges doppelt gemoppelt war. Ich habe jetzt unter
/run auch kein Verzeichnis generator-late mehr.
Allerdings ist das ein Desktop und kein Laptop, der nur von mir allein genutzt wird.
Aber die Startzeit hat sich im Gegensatz zu früher doch um einiges verkürzt.

[scientific]

Hab mal eine socket-unit für rsyslog eingebaut und sonstiges hin und her geschoben... unter 6s für das Userland kam ich nicht.

Dann hab ich ModemManager deaktiviert, da ich eh kein Modem am Laptop habe... und siehe da... 2s fürs Userland... mit dem Kernel (10s) ist der gdm nach 12s da...
Avahi-daemon, Networkmanager starten jetzt in wenigen ms... vorher bis zu 6 Sekunden... jeweils... nacheinander...

Was macht ModemManager so langsam beim Starten?

Lg s

[Knight]

Ich habe rigoros den kompletten Inhalt von /etc/init.d entsorgt

Was für ein Unterschied

Ich muß gestehen, ich hab' keine Ahnung, was genau ich jetzt da gemacht habe, aber Sicherung ist da, und ich lasse mich darauf ein. Mal sehen, ob sich da irgendwelche Folgeerscheinungen zeigen.

[scientific]

Würd ich mal nicht so machen... ich schau mir die einzelnen initscrips an, und baue dann systemd-units dazu. Und wenn diese funktionieren, dann reiche ich diese per bugreport zu den Paketbetreuern.

[KP97]

Doch, das kann man ruhig so machen, ich habe absolut keine Nachteile entdecken können.
Es sind ja schon standardmäßig so gut wie alle Services vorhanden, es sei denn, man hat was Exotisches am Start.
Man muß natürlich vorher in /init.d schauen, ob auch alles abgedeckt wird.
Bei mir mußte ich zusätzlich für das Netzwerk eine Änderung vornehmen, das kann aber sehr gut an meinem System liegen, da ich
keinen Displaymanager und auch keinen Netzwerkmanager einsetze.
War aber nichts Großartiges, eigentlich ziemlich simpel.

[Knight]

Da ich ein Debian-Sid habe, ziehe ich sowieso 1-2x in der Woche ein Image. Vor experimentiellen Bastelschritten oder Löschaktionen sowieso.

Ich konnte bisher keinen Nachteil feststellen, außer daß diese ewig lange "Rödel-Liste" beim Booten wegfällt. Das System ist schneller bereit.
Ich hab' auch mit dem Schlimmsten gerechnet, etwa das die Kiste gar nicht mehr hochfährt, oder zumindest ein schwarzer Bildschirm. Aber nichts ...

[scientific]

Hmmm... irgendwie glücklich macht mich das jetzt nicht...
Wenn ich das ernst nehme, was du schreibst, dann sind die Macher von Debian böse oder dumme Typen, die rein zum ärgern der User nach dem Laden des Kernels haufenweise Software reingepappt haben, die keine weitere Funktion erfüllt, als Zeit und Energie zu verbraten...

Oder wie meinst du dass mit der lästigen Rödelliste?

[scientific]

Das Startskript von gpm ist bisher das einzige, das nicht direkt in eine systemd-unit umzusetzen ist... da brauch ich erst wieder ein hilfsscript.

[Dogge]

Code: Alles auswählen

ls /etc/init.d 
acpid                   checkroot.sh      hostname.sh            mountdevsubfs.sh       README         udev
alsa-utils              console-setup     hwclock.sh             mountkernfs.sh         reboot         udev-finish
anacron                 cron              kbd                    mountnfs-bootclean.sh  rmnologin      umountfs
atd                     cryptdisks        keyboard-setup         mountnfs.sh            rpcbind        umountnfs.sh
atop                    cryptdisks-early  killprocs              networking             rsync          umountroot
avahi-daemon            dbus              kmod                   network-manager        rsyslog        urandom
binfmt-support          exim4             lm-sensors             nfs-common             saned          vnstat
bluetooth               gdm3              lvm2                   pppd-dns               sendsigs       x11-common
bootlogs                gdomap            minissdpd              procps                 single
bootmisc.sh             halt              motd                   rc                     skeleton
checkfs.sh              hddtemp           mountall-bootclean.sh  rc.local               smartmontools
checkroot-bootclean.sh  hdparm            mountall.sh            rcS                    sudo

Irgendwie bin ich skeptisch, dass man das alles einfach löschen kann.

[KP97]

Du brauchst ja nicht sofort löschen, ein verschieben/auskommentieren tut es doch erstmal auch.
In /lib/systemd/system finden sich alle targets und service-Dateien, da kann man schon vorher mal gucken, ob alles da ist.
Zu crypt und lvm2 kann ich nichts sagen, habe ich nicht, aber sonst sehe ich nichts Besonderes. Evtl. müssen einige Services nachgestartet werden, das sieht man dann. Aber man sollte sich vorher doch schon mit den Grundlagen von systemd befaßt haben, damit man auch entsprechend reagieren kann.
Also...Versuch macht kluch...

[Knight]

Wenn ich das ernst nehme, was du schreibst

Das war keinesfalls böse gemeint. Ich finde das was KP97 hier testet einfach nur interessant und auch logisch. Sollte ja auch das eigentliche Ziel von systemd sein, soweit ich das bisher begriffen habe.
Denke aber, es wird noch eine Weile dauern, bis sich das gefestigt hat.

Nachtrag: Ich hab' hier parallel ein Antergos am Laufen. Da gibt es den Ordner init.d schon gar nicht mehr.

[scientific]

Ich weiß, dass das Ziel von systemd jenes ist.
Aber die Aussage "das unnötige Gerödel beim Booten..." find ich seltsam.

Es hat wohl einen Grund, warum es /etc/init.d/ noch gibt.

Ich nehme an, dass sowohl Maintainer und Produzenten noch keine systemd-units geschrieben haben... oder die Tests noch nicht zufriedenstellend sind...

Und wenn ich mit gpm ansehe, ist das Format des config-files nicht systemd-tauglich... und am "falschen" Ort unter /etc/default/...

Da muss auch noch das configure-Skript angepasst werden... und das tat sich offenbar noch niemand an.

Wenn ich gpm nicht brauche... gut... aber ich habs gern... also "brauch ichs" und kann damit init.d nicht einfach so löschen.

Sowas zu empfehlen ist unverantwortlich.

Meine Meinung!

[KP97]

Sowas zu empfehlen ist unverantwortlich.

Ich habe in meinen Beiträgen darauf hingewiesen, was man vorher beachten bzw. prüfen sollte. Und ein auskommentieren des Ordners
ändert noch nichts am System, das ist ein reiner Test, weiter nichts.
Wenn einem das Ergebnis nicht gefällt, entfernt man halt das Kommentarzeichen und gut ist. Es ist auch niemand gezwungen, irgendwelche Vorschläge direkt in die Tat umzusetzen. Das kommt immer auf den jeweiligen User und den Kenntnisstand an.

Was daran jetzt "unverantwortlich" sein sollte, kann ich nicht erkennen.

[wurstLpz]

also bei mir unter Jessie64-lxde-core wird dann keine Netzwerkverbindung mehr aufgebaut, wenn ich den Inhalt von /etc/init.d lösche. Die Zeitersparnis beim booten betrifft genau die 3 Sekunden die durch den networking.service verbraucht werden.

Bootup mit den Skripten in /etc/init.d

Code: Alles auswählen

systemd-analyze && systemd-analyze blame

38482

Bootup ohne die Skripten in /etc/init.d

Code: Alles auswählen

systemd-analyze && systemd-analyze blame

38483

Networkmanager oder Wicd habe ich nicht installiert.
Ich stelle eine Kabelverbindung per dhcp zum Router via "dhcpcd" her.

Jetzt muss ich nur noch testen ob

Code: Alles auswählen

systemctl enable dhcpcd@eth0.service

funktioniert hat und ich nach dem reboot eine Verbindung habe...

[JTH]

Jetzt muss ich nur noch testen ob

Code: Alles auswählen

systemctl enable dhcpcd@eth0.service

funktioniert hat und ich nach dem reboot eine Verbindung habe...

Das wird leider so nicht funktionieren, da es das Service-Template dhcpd@.service in Debian (bisher) nicht gibt – es sei denn, du hast es selbst angelegt.

Du kannst aber systemd-networkd und systemd-resolved statt dem dhcpd und /etc/init.d/networking ausprobieren. Dazu müsstest du die beiden für den nächsten Boot aktivieren

Code: Alles auswählen

# systemctl enable systemd-networkd.service
# systemctl enable systemd-resolved.service

die resolv.conf passend verlinken

Code: Alles auswählen

# mv /etc/resolv.conf /etc/resolv.conf.old
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

und eine Konfigurationsdatei /etc/systemd/network/eth0.network mit folgendem Inhalt anlegen:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
# hier kann v4, v6 oder both stehen, je nachdem was du verwendest
DHCP=v4

[wurstLpz]

perfekt, vielen Dank für die Lösung, JTH.

Nach deinen Vorschlägen geändert, ist "/etc/init.d" nun leer und mein Bootup liegt unter 5 Sekunden.
38484

[JTH]

Code: Alles auswählen

            18ms resolvconf.service

Wenn du es nicht bewusst verwendest, kannst du denke ich auch noch auf resolvconf verzichten (das Paket entfernen).

[wurstLpz]

Code: Alles auswählen

            18ms resolvconf.service

Wenn du es nicht bewusst verwendest, kannst du denke ich auch noch auf resolvconf verzichten (das Paket entfernen).

hatte es nicht bewußt genutzt daher einmal testweise deinstalliert, danach gibt es keine Internetverbindung mehr.
Hatte dann "dhclient eth0" gestartet um eine Verbindung zu bekommen und das Paket "resolvconf" erneut zu installieren.

Hat auch funktioniert, nur merkt sich das System jetzt den DNS Server nicht mehr, erst wenn ich mit "network-admin" den DNS-Server (192.168.0.1) eingebe bekomme ich eine Verbindung, die ist allerdings nach jedem reboot weg.

Wo kann ich denn den DNS Server dauerhaft eingeben?

[JTH]

resolvconf solltest du problemlos entfernen können. Nach dem Entfernen kannst du entweder den DNS-Server manuell festlegen oder die Konfiguration auch deinem DHCP-Server überlassen.

Fürs manuelle Festlegen schreibst du

Code: Alles auswählen

nameserver 192.168.0.1

in die /etc/resolv.conf. Vorher musst du evtl. noch drauf achten, dass die Datei nicht mehr nach /run/systemd/resolve/resolv.conf verlinkt ist. Da kannst dann systemd-resolved auch wieder abschalten:

Code: Alles auswählen

# systemctl disable systemd-resolved.service

Wenn du das nicht manuell machen willst, müsstest du nach dem Entfernen von resolvconf noch mal gucken, ob /etc/resolv.conf richtig nach /run/systemd/resolve/resolv.conf verlinkt ist. Das sollte dann eigentlich reichen.

[wurstLpz]

jetzt ist der SymLink von "/etc/resolv.conf" nach "/etc/resolvconf/resolv.conf" weg (auch die *.old)
und die Datei "/etc/resolv.conf" ist wieder vorhanden, jetzt läuft es wieder.