Zum Inhalt springen

Init/System: Unterschied zwischen den Versionen

Aus Foxwiki
Zeile 62: Zeile 62:
# Upstart erfordert zum Verändern eine Modifikation des Skriptes, welches der Distributor mitliefert. Etwas das normalerweise nur in Ausnahmefällen gemacht werden sollte! Ab Version 1.3 gibt es hierzu auch die Möglichkeit der sogenannten „Override Files“
# Upstart erfordert zum Verändern eine Modifikation des Skriptes, welches der Distributor mitliefert. Etwas das normalerweise nur in Ausnahmefällen gemacht werden sollte! Ab Version 1.3 gibt es hierzu auch die Möglichkeit der sogenannten „Override Files“
# Weder SysVinit noch Upstart bieten eine zuverlässige Möglichkeit, um unabhängig von der aktuellen Position definiert ein bestimmtes Runlevel zu erreichen
# Weder SysVinit noch Upstart bieten eine zuverlässige Möglichkeit, um unabhängig von der aktuellen Position definiert ein bestimmtes Runlevel zu erreichen
== 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>
<noinclude>

Version vom 28. Januar 2025, 10:27 Uhr

Init/System

Beschreibung

Vorgänge beim Starten eines Computers

BIOS/UEFI wird gestartet
Bootloader wird gestartet
Kernel
Init Nachdem auch dieser Vorgang abgeschlossen ist, folgt der Start des ersten „richtigen“ Prozesses auf einem Unix-System: Das 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 SysVinit in Shellskripte niedergeschrieben sind
  • Dazu kommen noch einige Konfigurationsdateien der vielen Dienste, welche man heute auf einem modernen System vorfindet

Anwendung

Aktionen

Aktionen im Vergleich
Aktion SysVinit upstart systemd
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
Vorteile
  1. SysVinit erfordert in jedem Skript eine bestimmte, aber unterschiedliche Logik zum Starten, Neustarten und Beenden des Dienstes
  2. Upstart erfodert zum Aktivieren/Deaktivieren eine Modifikation des Jobs
  3. Upstart erfordert zum Verändern eine Modifikation des Skriptes, welches der Distributor mitliefert. Etwas das normalerweise nur in Ausnahmefällen gemacht werden sollte! Ab Version 1.3 gibt es hierzu auch die Möglichkeit der sogenannten „Override Files“
  4. Weder SysVinit noch Upstart bieten eine zuverlässige Möglichkeit, um unabhängig von der aktuellen Position definiert ein bestimmtes Runlevel zu erreichen


Anhang

Siehe auch

Links

Weblinks