|
|
| (13 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 2: |
Zeile 2: |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| Vorgänge beim Starten eines [[Computer]]s
| | |
| {| class="wikitable options" | | == Anwendung == |
| | BIOS || [http://de.wikipedia.org/wiki/BIOS BIOS]/[http://de.wikipedia.org/wiki/UEFI UEFI] wird gestartet
| | ==== Aktionen ==== |
| | ; Aktionen im Vergleich |
| | {| class="wikitable sortable" |
| |- | | |- |
| | Bootloader || Nach diesem Schritt wird der [http://wiki.ubuntuusers.de/Bootloader Bootloader] gestartet, in der Regel ist [http://wiki.ubuntuusers.de/GRUB_2 GRUB 2] in Gebrauch | | | | '''Aktion ''' |
| * Dieser kümmert sich darum den Linux-[http://wiki.ubuntuusers.de/Kernel Kernel] und die [http://de.wikipedia.org/wiki/initrd Initial Ramdisk:] zu laden
| | | | '''SysVinit ''' |
| | | | '''upstart ''' |
| | | | '''systemd ''' |
| |- | | |- |
| | Kernel || | | | | '''Dienst starten ''' |
| | | | /etc/init.d/dienstname start |
| | | | initctl start dienstname |
| | | | systemctl start dienstname.service |
| | |- |
| | | | '''Dienst aktivieren ''' |
| | | | Symlink in rcX.d |
| | | | Manipulation Job oder Override File |
| | | | systemctl enable dienstname.service |
| | |- |
| | | | '''Dienst neustarten ''' |
| | | | /etc/init.d/dienstname restart |
| | | | initctl restart dienstname |
| | | | systemctl restart dienstname.service |
| | |- |
| | | | '''Dienst ändern ''' |
| | | | Modifikation des Init-Skripts |
| | | | Modifikation Job oder Override File |
| | | | Überschreiben des Distributorskripts in /etc |
| | |- |
| | | | '''Runlevel ändern ''' |
| | | | telinit runlevel |
| | | | telinit runlevel |
| | | | systemctl isolate runlevel.target |
| |- | | |- |
| | Init || Nachdem auch dieser Vorgang abgeschlossen ist, folgt der Start des ersten „richtigen“ Prozesses auf einem Unix-System: Das [http://de.wikipedia.org/wiki/Init Init]-System
| |
| * Aufgabe dieses Init-Systems ist es, das System für den Benutzer in einen brauchbaren und definierten Zustand zu überführen:
| |
| * Ohne dieses würde man nur auf einer Shell sitzen, bei welcher die Übersetzung, Uhrzeit, Netzwerk oder viele andere Sachen fehlen würde
| |
| * Auch ein Mehrbenutzerbetrieb wäre – mangels gestarteter Dienste hierzu – nicht möglich
| |
| * Um diesen definierten Zustand zu erreichen, folgt dieses Init-System bestimmten Regeln, welche beim gängigen [http://de.wikipedia.org/wiki/SysVinit SysVinit] in Shellskripte niedergeschrieben sind
| |
| * Dazu kommen noch einige Konfigurationsdateien der vielen Dienste, welche man heute auf einem modernen System vorfindet
| |
| |} | | |} |
|
| |
| == 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 [http://de.wikipedia.org/wiki/Don’t_repeat_yourself DRY-Prinzip] zu entsprechen
| |
| * Die Skripte können je nach Distribution an unterschiedlichen Orten, zum Beispiel <tt>/etc/rc.d</tt> oder <tt>/etc/init.d</tt>, liegen, und auch die Aktivierung und Deaktivierung von Diensten kann abhängig von der Distribution unterschiedlich erfolgen – zum Beispiel durch symbolische Links in <tt>/etc/rcX.d</tt> oder einem Eintrag in der <tt>/etc/rc.conf</tt>
| |
| * 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 [http://wiki.ubuntuusers.de/killall 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 [http://de.wikipedia.org/wiki/Nagios Nagios] oder [http://de.wikipedia.org/wiki/Icinga 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 [http://de.wikipedia.org/wiki/Ereignis_%28Programmierung%29 Events] geregelt
| |
| * Upstart ist der erste Schritt zur Vereinfachung der Init-Skripte, welche nun unter <tt>/etc/init</tt> 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 [http://wiki.ubuntuusers.de/ln#Symbolische-Verknuepfungen 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 [https://fedoraproject.org/de/ Fedora] verwendet
| |
| * Viele Entwickler sind aber nicht bereit an Upstart mitzuentwickeln, da Canonical hierzu eine [http://www.canonical.com/contributors Beitragszustimmung] verlangt
| |
|
| |
| ==== OpenRC ====
| |
| [http://en.wikipedia.org/wiki/OpenRC OpenRC]
| |
| * häufig bei [http://de.wikipedia.org/wiki/Gentoo Gentoo]-Systemen
| |
|
| |
| == Vergleich ==
| |
| Hierzu einen Dienst bei allen drei Systemen im Vergleich
| |
|
| |
| Ausgewählt wurde hierzu [http://wiki.ubuntuusers.de/cron 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 [http://wiki.ubuntuusers.de/postfix 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 <tt>/etc/rcX.d</tt> (Debian/Ubuntu) beziehungsweise <tt>/etc/systemd/system</tt>
| |
| * Zur Verwaltung dieser Links gibt es auf einem Debian oder Ubuntu System das Tool update-rc.d
| |
| * Für systemd gibt es <tt>systemctl enable dienst.service</tt>, 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 [http://wiki.ubuntuusers.de/GDM GDM], [http://wiki.ubuntuusers.de/KDM 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
| |
|
| |
| <noinclude>
| |
|
| |
|
| == Anhang == | | == Anhang == |
| === Siehe auch === | | === Siehe auch === |
| {{Special:PrefixIndex/{{BASEPAGENAME}}}} | | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| ==== Links ====
| | === Links === |
| ===== Weblinks =====
| | ==== Weblinks ==== |
|
| |
|
| [[Kategorie:Linux/Dienst]] | | [[Kategorie:Linux/Dienst]] |