Init/System
Erscheinungsbild
Init/System
Beschreibung
Vorgänge beim Starten eines Computers
| BIOS | BIOS/UEFI wird gestartet |
| Bootloader | Nach diesem Schritt wird der Bootloader gestartet, in der Regel ist GRUB 2 in Gebrauch
|
| Kernel | |
| Init | Nachdem auch dieser Vorgang abgeschlossen ist, folgt der Start des ersten „richtigen“ Prozesses auf einem Unix-System: Das Init-System
|
Entwicklung
Im Laufe der Entwicklung hin zu modernen Unix-Systemen wurde vieles an grundlegender Software immer wieder modernisiert, dazu gehört auch das Init-System, welches für das Starten von Prozessen verantwortlich ist
SysVinit
- SysVinit ist ein System zum Starten von Diensten
- Grundlegendes Design von 1983
- Daher gibt es weder Abhängigkeiten, noch Events und so wird dieses System modernen Desktops und Notebooks nicht mehr gerecht
- Dienste werden hier strikt der Reihe nach gestartet, unabhängig davon, ob diese parallel gestartet werden könnten
- SysVinit setzt auf viele Skripte, welche in weiten Teilen ähnliche oder sogar gleiche Aufgaben erledigen
- Häufig benutzte Funktionen wurden aber mit der Zeit auf gemeinsam genutzte Skripte (Includes) ausgelagert, um zumindest im Ansatz dem DRY-Prinzip zu entsprechen
- Die Skripte können je nach Distribution an unterschiedlichen Orten, zum Beispiel /etc/rc.d oder /etc/init.d, liegen, und auch die Aktivierung und Deaktivierung von Diensten kann abhängig von der Distribution unterschiedlich erfolgen – zum Beispiel durch symbolische Links in /etc/rcX.d oder einem Eintrag in der /etc/rc.conf
- Für SysVinit ist es nicht zuverlässig möglich, Dienste sauber zu beenden
- In der Regel wird das Skript entweder einen Prozess anhand seiner gespeicherten Prozess-ID beenden oder aber mit killall alle in Frage kommenden Prozesse beenden
- Ausnahme hiervon sind Dienste, welche eine eigene Logik zum Beenden haben
- Ein bekannter Dienst welcher sich beispielsweise nicht sauber beenden lässt, wäre NRPE, der für Monitoring über Nagios oder Icinga benötigt wird
Upstart
- Neuentwicklung eines Init-Systems
- Im Gegensatz zu dem nachfolgend beschriebenen systemd, welches mit Abhängigkeiten arbeitet, wird hier alles über Events geregelt
- Upstart ist der erste Schritt zur Vereinfachung der Init-Skripte, welche nun unter /etc/init liegen
- Ein weiterer Unterschied ist, dass zum Deaktivieren eines Services die Events im Init-Skript deaktiviert werden müssen (bis Version 1.3)
- systemd arbeitet hier wie auch schon SysVinit mit Symbolischen Verknüpfungen
- Upstart greift bei weitem nicht so tief in ein vorhandenes System ein
- Unter anderem wird auch nicht verlangt Konfigurationen über bestimmte, vorgegebene, Konfigurationsdateien zu erledigen
- Die Dokumentation wurde vor allem in den letzten Versionen stark ausgebaut
- Dies war früher ein häufiger Kritikpunkt
- Upstart wurde neben Ubuntu auch eine Zeit lang von anderen Distributionen wie zum Beispiel Fedora verwendet
- Viele Entwickler sind aber nicht bereit an Upstart mitzuentwickeln, da Canonical hierzu eine Beitragszustimmung verlangt
OpenRC
- häufig bei Gentoo-Systemen
Vergleich
Hierzu einen Dienst bei allen drei Systemen im Vergleich
Ausgewählt wurde hierzu cron, der auf den meisten Systemen zu finden ist
SysVinit
#!/bin/sh
# Start/stop the cron daemon
#
### BEGIN INIT INFO
# Provides: cron
# Required-Start: $syslog $time
# Required-Stop: $syslog $time
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Regular background program processing daemon
# Description: cron is a standard UNIX program that runs user-specified
# programs at periodic scheduled times. vixie cron adds a
# number of features to the basic UNIX cron, including better
# security and more powerful configuration options
### END INIT INFO
test -f /usr/sbin/cron || exit 0
#LSBNAMES='-l' # Uncomment for LSB name support in /etc/cron.d/
. /lib/lsb/init-functions
case "$1" in
start) log_daemon_msg "Starting periodic command scheduler" "crond"
start-stop-daemon --start --quiet --pidfile /var/run/crond.pid --name cron --startas /usr/sbin/cron -- $LSBNAMES
log_end_msg $?
;;
stop) log_daemon_msg "Stopping periodic command scheduler" "crond"
start-stop-daemon --stop --quiet --pidfile /var/run/crond.pid --name cron
log_end_msg $?
;;
restart) log_daemon_msg "Restarting periodic command scheduler" "crond"
start-stop-daemon --stop --retry 5 --quiet --pidfile /var/run/crond.pid --name cron
start-stop-daemon --start --quiet --pidfile /var/run/crond.pid --name cron --startas /usr/sbin/cron -- $LSBNAMES
log_end_msg $?
;;
reload|force-reload) log_daemon_msg "Reloading configuration files for periodic command scheduler" "crond"
# cron reloads automatically
log_end_msg 0
;;
*) log_action_msg "Usage: /etc/init.d/cron {start|stop|restart|reload|force-reload}"
exit 2
;;
esac
exit 0
Upstart
# cron - regular background program processing daemon # # cron is a standard UNIX program that runs user-specified programs at # periodic scheduled times description "regular background program processing daemon" start on runlevel [2345] stop on runlevel [!2345] expect fork respawn exec cron
systemd
[Unit] Description=Periodic Command Scheduler
[Service] ExecStart=/usr/sbin/crond -n ExecReload=/bin/kill -HUP $MAINPID Restart=always
[Install] WantedBy=multi-user.target
Zusammenfassung
- Grundlegend machen alle drei Varianten das Gleiche
- Jedoch ist es bei SysVinit nicht ganz so einfach zu sehen, was genau passiert
- Cron ist in diesem Fall ein sehr einfaches Beispiel, Dienste wie zum Beispiel postfix haben wesentlich komplexere Init-Skripte, wohingegen die Komplexität von upstart Jobs oder systemd Units nur unwesentlich zunimmt
- Der upstart-Job wäre, wenn er in /etc/init liegt, schon direkt aktiviert und würde beim Starten des Systems abgearbeitet werden
- SysVinit und systemd erfordern hierzu Links in /etc/rcX.d (Debian/Ubuntu) beziehungsweise /etc/systemd/system
- Zur Verwaltung dieser Links gibt es auf einem Debian oder Ubuntu System das Tool update-rc.d
- Für systemd gibt es systemctl enable dienst.service, welches sich um das Anlegen des Links kümmert
- Im systemd-Unit wurde hier übrigens definiert, dass cron.service zum Target multi-user.target gehört, das entspricht einem Mehrbenutzerrunlevel im normalen SysVinit ohne grafische Oberfläche
- Wer jetzt glaubt im grafischen Modus (mit GDM, KDM, ...) keinen cron haben zu können, irrt:
- Targets können von anderen Targets abhängen und so definiert beispielsweise graphical.target – welches bei den meisten Distributionen der Standard ist – dass doch bitte zuerst multi-user.target gestartet werden möchte
- Die WantedBy Definition ist übrigens nur ein Vorschlag für systemctl
- Es ist jederzeit möglich durch eigene Symlinks unterhalb von /etc/systemd/system/ das Verhalten und die Reihenfolge zu modifizieren
- Unabhängig davon werden jedoch andere Abhängigkeiten der einzelnen Units beachtet
- Dies führt zum Beispiel immer dazu, dass Avahi gestartet wird, wenn ein Dienst diesen benötigt, unabhängig davon, in welchem Target der Dienst gestartet wird
Anhang
Siehe auch
Links
Weblinks