Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Alle zusammen

Die komplette Job-Datei der Messstation zeigt noch einmal Listing 2 . Neu sind dort nur die ersten beiden Zeilen: Hinter »description« steht eine Beschreibung des Jobs, hinter »author« der Verfasser. Beide Angaben informieren Administratoren über den Zweck des Jobs und nennen einen Ansprechpartner.

Listing 2

messen.conf

 

Sobald das Ereignis »filesystem« eintritt, aktiviert Upstart den Job. Gleichzeitig setzt es das Ereignis »starting messen« ab, auf das andere Jobs reagieren können. Außerdem führt es die Shell-Befehle hinter »pre-start script« aus. Sobald das geschehen ist, aktiviert es den Dienst »/usr/bin/messd« und verkündet gleichzeitig das Ereignis »started messen« . Diesen Ablauf veranschaulicht noch einmal Abbildung 5 .

Abbildung 5: Der Lebenslauf eines Jobs: In der linken Spalte stehen die Ereignisse, rechts die von Upstart ausgeführten Aktionen.

Altes Laufniveau

Viele Softwarepakete bringen noch keine Job-Dateien, sondern nur ältere System-V-Init-Skripte mit. Das gilt sogar für die meisten Dienste aus den aktuellen Ubuntu-Repositories. Wer beispielsweise den Apache-Webserver installiert, sucht unter »/etc/init« vergeblich eine passende Job-Datei. Stattdessen wandert wie zu guten alten Zeiten ein System-V-Init-Skript ins Verzeichnis »/etc/init.d« . Damit solche alten Skripte unter Ubuntu nicht über Nacht nutzlos werden, greift Upstart zu einem kleinen Trick: Ganz zum Schluss aktiviert es den Job »rc« , welcher das Skript »/etc/init.d/rc« ausführt. Dieses wiederum arbeitet alle alten SystemV-Init-Skripte unter »/etc/init.d« ab. Den dabei zu verwendenden Runlevel zieht Upstart entweder aus der Datei »/etc/inittab« oder übernimmt ihn von der Kernel-Kommandozeile. Im Zweifelsfall gilt der Runlevel 2, der zu einem System mit grafischer Oberfläche im Netzwerkbetrieb führt.

Soll ein Job erst zusammen mit den Skripten eines bestimmten Runlevels anlaufen, verwendet man das »runlevel« -Ereignis:

start on runlevel [23]

In diesem Fall würde der Job nur in den Runlevels 2 und 3 starten – und zwar parallel zu allen darin liegenden Skripten. Das »runlevel« -Ereignis erzeugt Upstart, sobald es die System-V-Init-Skripte eines Runlevels abarbeitet. Anhalten lässt sich ein solcher Job analog:

stop on runlevel [!2345]

Das Ausrufezeichen steht hier für die Verneinung.

Des Weiteren imitiert Upstart das Verhalten des alten System-V-Init. So kann man weiterhin mit

telinit 2

in den Runlevel 2 wechseln, auch »reboot« und »shutdown« funktionieren weiterhin wie gewohnt. Unter der Haube sendet »telinit« jetzt allerdings nur ein entsprechendes Ereignis an Upstart. Den Standard-Runlevel setzt man zudem in der Job-Datei »rc-sysinit.conf« hinter der Variablen »DEFAULT_RUNLEVEL« .

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023