openSUSE:Paketbau Init-Skripte

Wechseln zu: Navigation, Suche
Paketbau
Dieses Dokument beschreibt die Richtlinien für die Init-Skripte SysV-style zur Verwendung und Einfügung in Pakte von openSUSE. Sie sind They are LSB konform.

Bezeichnung

Die Bezeichnung von Init-Skripten muss LSB-verträglich sein. Es muss auf http://www.lanana.org/lsbreg/init/init.txt aufgeführt sein. Eine neue Bezeichnung kann, wie auf der Seite http://www.lanana.org/lsbreg/instructions.html beschrieben, registriert werden.

Struktur

Die Struktur von Init-Skripten ist gut in /etc/init.d/skeleton beschrieben. Diese Datei kann ebenso als eine effiziente Vorlage für neue Init-Skripte verwendet werden.

LSB Header

Init-Skripte sind Shell-Skripte. Die Datei beginnt mit dem Gewöhnlichen Header: 

#!/bin/sh

oder 

#!/bin/bash

Dann gibt es die gewöhnlichen Kommentare. Diese sollten die Informationen über Autor, Urheberrecht oder Lizenzen erwähnen. Diese datei muss einen speziellen Kommentar-Header beinhalten, der einige Metainformationen über das Init-Skript enthält. Der LSB-Header ist auf Kommentare beschränkt. Speziell der Anfang des Headers wird mir: 

### BEGIN INIT INFO

gekennzeichnet. Der Schluss des LSB-Headers ist mit: 

### END INIT INFO

gekennzeichnet. Alle LSB-Header müssen diese Grenzkommentare besitzen.

Dieses Beispiel ist aus /etc/init.d/esound: entnommen: 

 # 1995-2002, 2008 SUSE Linux Products GmbH, Nuernberg, Germany.
 # Alle Rechte vorbehalten.
 #
 # Author: Stanislav Brabec, feedback to http://www.suse.de/feedback
 #
 ### BEGIN INIT INFO
 # Provides:          esound
 # Required-Start:    alsasound $remote_fs
 # Should-Start:      $network $portmap
 # Required-Stop:     alsasound $remote_fs
 # Should-Stop:       $network $portmap
 # Default-Start:     5
 # Default-Stop:
 # Short-Description: Sound-Daemon mit Netzwerkunterstützung
 # Description:       Startet Esound-Server, um den entfernten 
 #                    Zugriff auf Sound-Karte zu erlauben. Um den
 #       Esound lokal zu nutzen, müssen Sie den Server 
 #       nicht beim Booten starten. Sie sollten die Server
 #       Einstellungen vor dem Start via 
 #       sysconfig Editor: Network/Sound/Esound bearbeiten.
 ### END INIT INFO

Der LSB-Header ist aus folgenden Abschnitten zusammengestellt:

# Provides: Zeile

Die Zeile # Provides: im LSB-Header listete jede Boot-Einrichtung, den der Service unterstützt, auf. Andere Service können sich auf diese Booteinrichtungen in den Zeilen # Required-Start: und # Required-Stop: beziehen. Es ist gewöhnlich der Name des Daemon. Wenn mehr als ein Paket die gleiche Einrichtung unterstützt (z. B. sendmail vs. postfix, dhcpcd vs. dhclient), sollten die Init-Skripte von beiden den gleichen Einrichtungsnamen unterstützen. 

# Provides: boot_facility_1 [boot_facility_2...]

Wenn ein Init-Skript mit einem Startargument läuft, sollten die Booteinrichtung oder die Einrichtungen, die durch das Provides-Schlüsselwort spezifiziert werden, als anwesend gelten und daher sollten Init-Skripte, die diese Booteinrichtungen benötigen, später gestartet werden. Wenn ein Init-Skript mit einem Stoppargument läuft, gilt die Booteinrichtung, die durch das Provides-Schlüsselwort spezifiziert ist, nicht länger als anwesend.

# Required-Start: Zeile

Die Zeile # Required-Start: line im LSB Header listet alle Booteinrichtungen auf, die während des Starts dieses Service verfügbar sein müssen. 

# Required-Start: boot_facility_1 [boot_facility_2...]

Diese Zeile ist zwingend. Wenn ein Init-Skript keine Notwendigkeit für eine andere Einrichtung vor dem Start hat, müssen Sie Required-Start verwenden, auch wenn es leer ist!

# Required-Stop: Zeile

Die Zeile # Required-Stop: im LSB Header listet alle Booteinrichtungen auf, die NICHT vor dem Ausschalten dieses Service gestoppt werden sollten. 

# Required-Stop: boot_facility_1 [boot_facility_2...]

Diese Zeile ist optional. Wenn ein Init-Skript keinen Bedarf zur Forderung, dass andere Booteinrichtung gestoppt werden müssen, nur nachdem es abgeschaltet ist, dann sollte die Zeile weggelassen werden.

# Should-Start: Zeile

Die Zeile # Should-Start: im LSB Header listet jede Einrichtung auf, die, wenn vorhanden, zur Verfügung stehen sollte während des Starts dieses Service. Die Absicht ist, "optionale" Abhängigkeiten zu erlauben, die nicht verursachen, dass der Service Fehler ausgibt, wenn der Service nicht Verfügbar ist. 

# Should-Start: boot_facility_1 [boot_facility_2...]

Diese Zeile ist optional. Wenn ein Init-Skript keinen Bedarf hat, andere optionale Abhängigkeiten zu starten, sollte sie weggelassen werden.

# Should-Stop: Zeile

Die Zeile # Should-Stop: im LSB Header listet jede Einrichtung auf, die, wenn er präsent ist, nur gestoppt werden sollte, nachdem dieser Service abgeschaltet ist. Die Absicht ist, "optionale" Abhängigkeiten zu erlauben, die nicht verursachen, dass der Service Fehl schlägt, wenn eine Einrichtung nicht verfügbar ist. 

# Should-Stop: boot_facility_1 [boot_facility_2...]

Diese Zeile ist optional. Wenn ein Init-Skript keinen Bedarf hat, andere optionale Abhängigkeiten so lange am Stoppen zu hindern, bis nachdem es abgeschaltet ist, sollte diese Zeile weggelassen werden.

LSB erlaubt Distributions-spezifische Erweiterungen zu diesem Header. Diese Schlüsselworte werden mit dem Präfix X-VendorTag- versehen.

# X-Start-Before: Zeile

Die Zeile # X-Start-Before: im LSB Header besagt, dass das Skript, das dieses Schlüsselwort verwendet, vor den spezifizierten Einrichtungen starten sollten. 

# X-Start-Before: boot_facility_1 [boot_facility_2...]

Diese Zeile ist optional und momentan Anbieter spezifisch (openSUSE).

# X-Stop-After: Zeile

Die zeile # X-Stop-After: im LSB Header besagt, dass das Skript, das das Schlüsselwort verwendet, nach den spezifizierten Einrichtungen gestoppt werden sollte. 

# X-Stop-After: boot_facility_1 [boot_facility_2...]

Diese Zeile ist optional und momentan Anbieter spezifisch (openSUSE).

Beide # X-Start-Before: und # X-Stop-After: erlauben Skript-Schreibern, Abhängigkeiten im neuen Skript zu verwenden, ohne andere zu modifizieren, z. B. System-Init-Skripte.

# Default-Start: Zeile

Die Zeile # Default-Start: im LSB Header listet die Laufebenen (runlevels) auf, für welche der Service standardmäßig aktiviert werden wird. Diese Laufebenen sind Raum-aufgeteilt. 

# Default-Start: run_level_1 [run_level_2...]

Jedes Init-Skript im SystemV-Stil, dass standardmäßig in jeder Laufebene gestartet werden muss, muss diese Zeile im LSB Header enthalten. Nur Service, die für eine vitales System wirklich erforderlich sind, sollten die Laufebenen hier definieren. Wenn der Service nicht standardmäßig in jeder Laufebene startet, sollte diese Zeile weggelassen werden. Zum Beispiel, wenn ein Service standardmäßig nur in den Laufebenen 3, 4 und 5 startet, würde der LSB Header im Init-Skript spezifizieren: 

# Default-Start: 3 4 5

# Default-Stop: Zeile

Die Zeile # Default-Stop: im LSB Header listet die Laufebenen auf, bei denen der Service nicht standardmäßig gestartet wird. Diese Laufebenen sind Raum-getrannt und müssen alle die numerischen Laufebenen enthalten, die nicht in der Zeile # Default-Start: verwendet werden. 

# Default-Stop: run_level_1 [run_level_2...]

Jedes Init-Skript im SystemV-Stil, das standardmäßig in irgend einer Laufebene gestartet werden muss, muss diese Zeile im LSB Header enthalten (wenn die Zeile # Default-Start: anwesend ist, denn da sollte auch eine Zeile # Default-Stop: geben.)

Zum Beispiel, wenn ein Service standardmäßig nur in den Laufebenen 3, 4 und 5 läuft, dann muss die Zeile # Default-Stop: im LSB Header die Laufebenen 0, 1, 2 und 6 angeben: 

# Default-Stop: 0 1 2 6
Bitte beachten Sie, dass # Default-Stop: in openSUSE ignoriert wird, weil das Boot-Skript-Konzept ein anderes Link-Schema verwendet, als auf der Manual-Seite init.d(7) beschrieben wird.

# Short-Description: Zeile

Die Zeile # Short-Description: im LSB Header unterstützt eine kurze Zusammenfassung der Aktionen im Init-Skript. Diese einzige Textzeile darf nicht länger als 80 Zeichen haben. 

# Short-Description: This service is a mail server.

Alle Init-Skripte im SysV-Stil müssen die Zeile # Short-Description: im LSB Header haben. Es kann grob als Äquivalent zum Feld Summary: in der RPM-Spezifikationsdatei betrachtet werden. Sie wird zum Beispiel im YaST-Runlevel-Editor angezeigt.

# Description: Zeile

Die Zeile # Description: im LSB Header unterstützt eine vollständigere Beschreibung der Aktionen des Init-Skripts. Es kann mehrere Zeilen umfassen, bei der jede weitere Zeile mit '#' beginnen muss, gefolgt von einem Tab-Zeichen oder einem '#' gefolgt von mindestens zwei Leerzeichen. Die mehrzeilige Beschreibung wird beendet durch die erste Zeile, die dieses Kriterium nicht erfüllt. Diese Information wird ebenso im YaST-Runlevel-Editor angezeigt.

Beispiel: 

# Description: Bluetooth Service für Service-Erkennung, Authentifizierung,
#              Mensch-Schnittstelle-Geräte, etc.

Alle openSUSE Init-Skripte im SysV-Stil müssen die Zeile # Description: im LSB Header enthalten. Sie kann grob als Äquivalent zum Abschnitt %description in der RPM-Spezifikationsdatei betrachtet werden.

Funktionen

Wie bei LSB gefordert unterstützen SUSE Linux Init-Skripte einige standardmäßige Funktionsbezeichnungen. Diese sind unter /etc/insserv.conf definiert. Gegenwärtig werden folgende Funktionsbezeichnungen unterstützt:

  • $local_fs — Alle lokalen Dateisysteme sind eingehängt. Die meisten Service sollten das benötigen.
  • $remote_fs — Alle fernen Dateisysteme sind eingehängt. Weil /usr könnte fern sein und das auch benötigen.
  • $syslog — Die System Anmeldefunktion ist eingestellt.
  • $network — Low Level Netzwerkverbindung (eth Karte, etc.) ist eingestellt.
  • $named — Hostname Auflösung ist verfügbar.
  • $netdaemons — Alle Netzwerk-Dämonen laufen. Das war in LSB 1.2 entfernt. Momentan ist es noch für die Rückwärtskompatibilität verfügbar.
  • $time — Die Systemzeit wurde korrekt eingerichtet.
  • $portmap — SunRPC Portmapping Service ist verfügbar.
  • $null — Durchsetzen einer leeren Abhängigkeit für den Fall von Required-Stop und Should-Stop, andererseits insserv nimmt die gleichen Abhängigkeiten an wie für den Startfall.

Neben den LSB konformen Systemfunktionen, wie in /etc/insserv.conf auf openSUSE definiert, sind die folgenden Systemfunktionen bekannt:

  • $all Diese Funktion zeigt an, dass ein Service am Ende aller Service eingefügt werden sollte. Genau genommen werden alle Service, die diese Funktion verwenden, in eine Startreihenfolge gruppiert.
  • $null wird verwendet, um eine leere Abhängigkeit für den Fall # Should-Stop: und # Required-Stop: durchzusetzen. Andernfalls nimmt insserv(8) die gleichen Abhängigkeiten an, wie unter # Should-Start: bzw. # Required-Start: spezifiziert.

Andere (nicht-System-)Funktionen können in der Zeile # Provides: im LSB Header definiert werden.

Aktionen

Betrachten Sie /etc/init.d/skeleton, der einen Beispielcode enthält und einige wertvolle Kommentareeinschließt. Das folgende Beispiel ist aus /etc/init.d/cron entnommen: 


case "$1" in
    start)
        echo -n "Starting CRON daemon"
        startproc $CRON_BIN
        rc_status -v
        ;;
    stop)
        echo -n "Shutting down CRON daemon"
        killproc -TERM $CRON_BIN
        rc_status -v
        ;;
    try-restart)
        $0 status >/dev/null &&  $0 restart
        rc_status
        ;;
    restart)
        $0 stop
        $0 start
        rc_status
        ;;
    force-reload)
        echo -n "Reload service Cron"
        checkproc $CRON_BIN
        rc_status -v
        ;;
    reload)
        rc_status -v
        ;;
    status)
        echo -n "Checking for Cron: "
        checkproc $CRON_BIN
        rc_status -v
        ;;
    probe)
        ;;
    *)
        echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload|probe}"
        exit 1
        ;;
esac

Wie durch LSB definiert, sollten alle Init-Skripte wissen, wie die folgenden Argumente zu handhaben sind:

  • start — Startet den Service.
  • stop — Stoppt den Service.
  • restart — Stoppt und startet den Service neu, wenn er bereits läuft. Andernfalls startet der Service.
  • reload — Verursacht die Konfiguration des Services, um neu geladen zu werden, ohne den Servis zu stoppen und neu zu starten.
  • force-reload — Verursacht die Konfiguration neu geladen zu werden, wenn der Service das unterstützt. Andernfalls wird der Service neu gestartet.
  • status — Druckt den momentanen Status des Service.
  • usage - per Standard sollte, wenn das Init-Skript ohne Aktionen läuft, es eine "Verwendungs-Nachricht" auflisten, die alle Aktionen enthält (zur Verwendung beabsichtigt).

start, stop, restart, force-reload und Status-Aktionen müssen von allen Init-Skripten unterstützt werden. Die Aktion reload ist optional.

SUSE definiert die folgenden zusätzlichen Aktionen:

  • try-restart — Neustart des Service nur wenn er vorher aktiv war. Diese Aktion ist nicht Bestandteil von LSB (wie von 1.9). Red Hat hat eine ähnliche Aktion, die mit condrestart bezeichnet wird.
  • probe — Untersucht, ob das Neuladen notwendig ist. Abhängig vom Service wird "reload" oder "restart" gedruckt, wenn das Neuladen gefordert ist. Nichts wird gedruckt, wenn Neuladen nicht gefordert ist. Diese Aktion ist optional und kein Bestandteil von LSB (wie von 1.9).

Init-Skripte im SystemV-Stil sollten die Aktionen try-restart und condrestart unterstützen. Diese zwei Aktionen sind dafür vorgesehen, identische Zwecke zu unterstützen und dürden sich im Verhalten nicht unterscheiden. Es wird stark empfohlen, dass Paketbauer try-restart und condrestart als gleichwertige Optionen in der Erklärung implementieren: 

try-restart|condrestart)
    $0 status
    if test $? = 0; then
        $0 restart
    else
        rc_reset
    fi
    rc_status
    ;;

Es ist nicht verboten, andere Kommandos hinzu zu fügen. Aber Sie sollten alle Kommandos auflisten, die Sie beabsichtigen interaktiv zu verwenden, zur Gebrauchsanweisung.

Ausstiegs-Status-Code

Referenz: Siehe LSB Spezifikation. Sie definiert die folgenden Ausstiegs-Status-Code für Init-Skripte (ausgenommen für Statusaktionen, siehe unten):


Ausstiegs-Status-Code Beschreibung
0 Erfolg
1 generischer oder unspezifizierter Fehler
2 ungültige oder überflüssige Argumente
3 nicht implementierte Funktion (z.B. "reload")
4 Benutzer hat ungeeignete Rechte
5 Programm ist nicht installiert
6 Programm ist nicht konfiguriert
7 Programm läuft nicht
8-99 reserviert für zukünftige LSB Anwendungen
100-149 reserviert für den Bedarf der Distribution
150-199 reserviert für Bedarf von Anwendungen
200-254 reserviert

Für alle anderen Init-Skript-Aktionen muss das Init-Skript einen Ausstiegs-Status von Null zurückgeben, wenn die Aktion erfolgreich war. Zusätzlich zum einfachen Erfolg werden die folgenden Situationen auch als erfolgreich betrachtet:

  • Neustart eines Service (anstelle von neu laden) mit dem Argument force-reload
  • start auslösen für einen Service, der bereits läuft
  • stop auslösen für einen bereits gestoppten oder nicht laufenden Service
  • restart auslösen für einen Service, der bereits gestoppt wurde oder nicht läuft
  • condrestart oder try-restart auslösen für einen Service, der bereits gestoppt wurde oder nicht läuft

Status-Funktionen

LSB definiert die folgenden Ausstiegs-Code als Status-Aktion:

Ausstieg-Status-Code Beschreibung
0 Programm läuft oder Service ist OK
1 Programm ist tot und /var/run PID-Datei ist vorhanden
2 Programm ist tot und /var/lock Lock-Datei ist vorhanden
3 Programm läuft nicht
4 Programm oder Service-Status ist unbekannt
5-99 reserviert für zukünftige LSB-Verwendung
100-149 reserviert für Distributions-Verwendung
150-199 reserviert für Anwendungs-Verwendung
200-254 reserviert

Die Funktionen, die in /etc/rc.status definiert sind, helfen die aktuellen rc-Status-Informationen in Init-Skripten zu erfassen, anzuzeigen und zurückzugeben. Sie können auf diese Weise in die Init-Skripte eingegeben werden: 

. /etc/rc.status

Die folgenden Funktionen sind verfügbar:

rc_active

Diese Funktion prüft, ob ein Service (mittels Symlinks) aktiviert ist. Sie gibt “0” wieder, wen der Service in einer Laufebene aktiviert ist und gibt “1” wieder, wenn nicht.

rc_exit

Diese Funktion beendet ein Init-Skript mit dem Ausstiegs-Status entsprechend dem allgemenen rc-Status.

rc_failed [num]

Diese Funktion setzt den lokalen und den allgemeinen rc-Status auf einen ausgewählten Wert, der durch den Parameter num definiert wird. Der Wert “1” wird standardmäßig verwendet.

rc_check

Diese Funktion prüft den Ausstiegsstatus des letzten Kommandos ($?) und setzt den lokalen rc-Status auf diesen Wert, wenn der Wert sich von “0” unterscheidet. Dann setzt sie den allemeinen rc-Status auf den Wert des lokalen rc-Status, wenn er von “0” abweicht. Diese Funktion wird von der rc-Status-Funktion intern genutzt.

rc_reset

Diese Funktion setzt sowohl den lokalen als auch den allgemeinen rc-Status auf “0”.

rc_status [-r] [-s] [-u] [-v[num]]

Diese Funktion prüft, stzt und zeigt den rc-Status an. Per Standard ist sie ruhig: sie ruft nur rc_check auf. Damit muss sie mit einer Option aufgerufen werden, um den Status anzuzeigen. Die Optionen haben die folgende Bedeutung:

  • -r ruft rc_reset auf. Diese Option ist gemeinsam mit -v verwendbar. Das Kommando rc_status -v -r prüft, setzt und zeigt den gegenwärtigen rc-Status. Dann wird rc_reset aufgerufen.
  • -s zeigt “skipped” und setzt den Status auf “3”. Das steht für eine nicht implementierte Funktion.
  • -u zeigt “unused” und setzt den Status auf “3”. Das steht für eine nicht implementierte Funktion.
  • -v[num] zeigt den aktuellen Status und setzt den lokalen Status neu auf “0”. Per Standard wird der Status auf der aktuellen Zeile angezeigt. Der Parameter num definiert, dass er num Zeilen über der aktuellen Cursorposition zeigen sollte.

Installation

Das Init-Skript ist gewöhnlich in den Paketquellen und einer extra Quelldatei enthalten. Es im Abschnitt %install installiert. Normaler Weise dürfen Init-Skripte nicht als %config Datei markiert werden.

Obwohl Init-Dateien unter /etc leben, sind sie Skripte, die auszuführen und nicht zu konfigurieren sind. Jede Konfiguration sollte durch /etc/sysconfig/<service> möglich gemacht werden und nicht im Init-Skript selbst. Eine geltende Ausnahme von dieser Regel würden vorhandene Pakete sein, bei denen die Konfiguration noch über die Init-Datei gemacht werden. In diesem Fall sollte die Init-Datei als %config markiert werden, das den Regeln des Abschnitts Konfigurationsdateien folgen, um die Konfiguration des Benutzers beim Aktualisieren zu erhalten, so dass der Benutzer besagte Konfiguration zu einer neuen /etc/sysconfig/<service> Konfigurations-Datei migrieren kann.

Init-Skripte müssen die Erlaubnisse 0755 oder 0700 haben.

Es könnte auch ein Symlink mit der Bezeichnung rcname geben, der auf /etc/init.d/name zeigt. Der Symlink ist entweder in /sbin oder in /usr/sbin abgelegt, abhängig vom Präfix, wo der Service installiert wird. Es ist für Init-Skripte nützlich, dass es von Hand gestartet, gestoppt und neu gestartet werden kann.

Zum Schluss, das Init-Skript kann nach der Installation des Paketes aktiviert werden und muss nachdem das Paket gelöscht wurde, deaktiviert werden. Der Service sollte nach einer Aktualisierung neu gestartet und bevor das Paket gelöscht wird, gestoppt werden. Folgende Makros sind für diesen Zweck beabsichtigt: %fillup_and_insserv, %insserv_force_if_yast, %restart_on_update, %insserv_cleanup und %stop_on_removal.

Beachten Sie, dass SUSE Linux unterstützt das Dienstprogramm insserv, um Init-Skripte zu aktivieren oder zu deaktivieren. Wir verweisen auf die Manpage von insserv(8) für weitere detaillierte Informationen. Dieses Dienstprogramm wird ebenfalls von folgenden Makros verwendet: %fillup_and_insserv, %insserv_force_if_yast und %insserv_cleanup.

Die Init-Skripte sind standardmäßig auf SUSE Linux deaktiviert, ausgenommen jener, die für minimale Systemfunktionen notwendig sind. Dafür werden die Makros %fillup_and_insserv und %insserv_force_if_yast nur in Paketen, die solche grundsätzlichen Service unterstützen, verwendet.

Beispiel für eine Spezifikationsdatei: 

...

Requires(pre): %insserv_prereq %fillup_prereq

...

%install

...

install -D -m 755 service.init %{buildroot}%{_initrddir}/service

...

mkdir -p %{buildroot}%{_sbindir}
ln -sf %{_initrddir}/service %{buildroot}%{_sbindir}/rcservice

...

%post
%fillup_and_insserv service

%preun
%stop_on_removal service

%postun
%restart_on_update service
%insserv_cleanup

...

%files
%defattr(-,root,root)
...
%{_initrddir}/service
%{_sbindir}/rcservice

...

Die Namen der Init-Skripte müssen als Parameter der betreffenden Makros aufgelistet werden, wenn sie aktiviert, neu getartet oder gestoppt werden müssen. Die einzige Ausnahme ist das Makro %insserv_cleanup. Es braucht keinen Parameter, da es alle anhängenden Symlinks ohnehin löscht.

Pakete mit Init-Skripten im SysV-Stil müssen alle in /etc/init.d gesteckt werden. Ein RPM-Makro für dieses Verzeichnis gibt es: %_initrddir.

Wie unterstützt LSB aktuelle Arbeit auf openSUSE

Ein auf LBS basierendes System verwendet /usr/lib/lsb/install_initd für die Skript-Aktivierung und /usr/lib/lsb/remove_initd für die Deaktivierung. Wenn diese Aufgaben anstehen, werden die LBS-Abhängigkeiten gelesen und die Start- und Stopp-Prioritäten der Skripte werden dann angepasst, um diese Abhängigkeiten zu erfüllen.

Das bedeutet, dass die LBS-Header-Abhängigkeiten anerkannt werden (wenn auch in einem statischen Mechanismus). Um die Abhängigkeiten im LBS-Header außer Kraft zu setzen, kann das Systemwerkzeug insserv(8) verwendet werden. Um weitere Informationen zu erhalten, wie man das macht, sollten die Anleitungsseiten von insserv(8) gelesen werden.

Initialisierung von Umgebungsvariablen

Da Init-Skripte von einem Systemadministrator mit Werten von nicht-Standard-Umgebungs-Variablen für PATH, USER, LOGNAME, etc. manuell zum Laufen gebracht werden können, sollten Init-Skripte nicht von den Werten dieser Umgebungsvariablen abhängen. Sie sollten auf bekannte Standard-Werte gesetzt werden, wenn sie benötigt werden.

Init-Skripte müssen in ihrem besten Verhalten sein

Init-Skripte im SystemV-Stil müssen sich sensibel verhalten, wenn sie gestartet werden, wenn der Service bereits läuft, oder gestoppt, wenn der Service nicht läuft. Sie dürfen nicht Benutzer-Prozesse ohne Bezug (aber ähnlich bezeichnet) als Ergebnis ihrer normalen Aktionen beenden. Der beste Weg, um das zu erreichen, ist es, die Init-Skript-Funktionen zu verwenden, die durch /etc/rc.status unterstützt werden: 

# Quell-Funktions-Bibliothek.
. /etc/rc.status
rc_reset

und die System-Werkzeuge /sbin/start_daemon oder /sbin/startproc, um einen Prozess zu starten, /sbin/killproc, um einen Prozess zu stoppen, und /sbin/checkproc, um einen laufenden Prozess zu überprüfen. Für weitere Erklärungen sollten die Anleitungsseiten von start_daemon(8) oder startproc(8), killproc(8) und checkproc(8) konsultiert werden.

Das Kommando startproc startet Prozesse, die durch den Pfad-Namen des ausführbaren Programms identifiziert wird. Der vorhandene Status ist LSB. Mehr Informationen finden Sie unter Ausstiegs-Status-Code. Es kann durch das Kommando start_daemon ersetzt werden, das sich nicht vor dem Start des ausführbaren Programms aufspaltet. Das erfordert, dass der neue Prozess sich selbst aufspaltet und vom Terminal abmeldet. (Lesen Sie dazu die Anleitungen startproc(8), daemon(3), fork(2) und setsid(2)).

Das LSB-Kommando killproc gibt ein Signal an Prozesse, die anhand der kompletten Pfad-Bezeichnung des ausführbaren Programms identifiziert werden. Lesen Sie dazu die Anleitungsseite killproc(8).

Das LSB-Kommando pidofproc verwendet die Basisbezeichnung um einen Prozess zu suchen. Das Kommando checkproc</code> verwendet den kompletten Pfad eines ausführbaren Programms, um das Gleiche zu machen. (Lesen Sie die Anleitung pidofproc(8)).

Dann gibt es die gewöhnlichen Überprüfungen, ob der Service korrekt installiert ist und die verbundenen sysconfig-Dateien gelesen werden. Die LSB-konformen Fehlerwerte müssen im Fall von Problemen zurückgegeben werden. Mehr Details finden Sie unter Ausstiegs-Status-Code

Dieses Beispiel wurde von /etc/init.d/ypbind: genommen. 

YPBIND_BIN=/usr/sbin/ypbind
 test -x $YPBIND_BIN || { echo "$YPBIND_BIN not installed";
         if [ "$1" = "stop" ]; then exit 0; else exit 5; fi; }
 
 YPBIND_CONFIG=/etc/sysconfig/ypbind
 test -r $YPBIND_CONFIG || { echo "$YPBIND_CONFIG not existing";
         if [ "$1" = "stop" ]; then exit 0; else exit 6; fi; }
 
 # Read config
 . $YPBIND_CONFIG


Wenn ein Service seine Konfiguration automatisch neu lädt (wie zum Beispiel im Fall von cron), muss die neu geladene Aktion des Init-Skripts sich verhalten, als ob die Konfiguration erfolgreich neu geladen wäre. Die Aktionen restart, condrestart, try-restart, reload und force-reload können automatisch erfolgen. Das ist so, wenn ein Service bekannt ist, nicht optional nach restart oder reload zu sein. Das Skript könnte einen Fehler ausgeben, ohne weitere Aktionen auszuführen.

System-Werkzeuge für SystemV-Init-Skripte

start_daemon(8) und startproc(8) Werkzeuge

  • start_daemon Startet einen Daemon, wenn er nicht bereits läuft.
  • startproc Startet einen Prozess, wenn er nicht bereits läuft.
start_daemon [-fLve] [-n +/-<prio>] [-u user] [-g group] [-l log_file|-q|-d] [-p pid_file]
          [-i ignore_file][-c root]/path/to/executable [arguments for executable]


startproc [-fLves] [[-n ]+/-<prio>] [-(t|T) <sec>] [-u user] [-g group] [-l log_file|-q|-d] [-p pid_file]
          [-i ignore_file] [-c root] /path/to/executable [arguments for executable]

killproc(8) Werkzeug

Sendet ein Signal zu dem Programm; standardmäßig sendet es SIGTERM. Und wenn der Prozess nicht stirbt sendet es SIGKILL einige Sekunden später. Es versucht auch die PID-Datei zu löschen, wenn es eine findet. 

killproc [-vqLN] [-g|-G] [-p pid_file] [-i ingnore_file] [-c root] [-t <sec>] [-<SIG>] /full/path/to/executable

killproc -n [-vq] [-g|-G] [-t <sec>] [-<SIG>] name_of_kernel_thread

killproc    [-vq] [-g|-G] [-t <sec>] [-<SIG>] basename_of_executable

checkproc(8) und pidofproc(8) Werkzeug

Versucht den Status und die PID eines Programms zu finden; prüft PID-Dateien. Hauptsächlich ist die pidofproc die ausführlichere Version von checkproc. 

checkproc [-vLkNz] [-p pid_file] [-i ingnore_file] [-c root] /full/path/to/executable

checkproc -n [-vk] name_of_kernel_thread

checkproc    [-vk] basename_of_executable

pidofproc [-LkNz] [-p pid_file] [-i ingnore_file] [-c root] /full/path/to/executable

pidofproc -n [-k] name_of_kernel_thread

pidofproc    [-k] basename_of_executable

LSB Shell-Functionen

Die oberen Systemwerkzeuge werden von Shell-Funktionen unterstützt, die in /lib/lsb/init-functions zu finden sind: 

# Lädt die LSB Shell Funktionen
. /lib/lsb/init-functions

gemeinsam mit der Zusammenfassung, die durch LSB 3.1 und höher spezifiziert wird: 

start_daemon [-f] [-n +/-<prio>] /path/to/executable [arguments for executable]
killproc [-p pid_file] /full/path/to/executable [-<SIG>]
pidofproc [-p pid_file] /full/path/to/executable
Abgerufen von „https://de.opensuse.org/index.php?title=openSUSE:Paketbau_Init-Skripte&oldid=30935“