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)

Die Start-Funktion

Läuft Asterisk nicht, soll der Agent den Dienst starten. An dieser Stelle spielt wieder Astcanary eine Rolle: Der wird von Asterisk selbst gestartet, sodass der Asterisk Agent sich darum nicht kümmern muss. Stirbt allerdings eine Asterisk-Instanz, so stirbt der dazugehörige Astcanary nicht automatisch mit. Deshalb muss die »start« -Funktion auch eventuelle Astcanary-Zombies aus dem Weg räumen, bevor sie einen neuen Asterisk starten kann.

Schließlich kommt die Funktion zu ihrer eigentlichen Aufgabe. Weil Agents nach dem OCF-Standard nicht distributionsspezifisch sein dürfen, fallen die distributionseigenen Werkzeuge wie »start-stop-daemon« auf Debian aus. Der Agent muss das Asterisk-Binary direkt aufrufen. Dazu konstruiert er aus den verschiedenen angegebenen Parametern einen Asterisk-Aufruf, den er dann mittels »ocf_run« ausführt. Zuvor stellt er noch sicher, dass die Ordner, die Asterisk zum Funktionieren braucht, existieren und dass der per Parameter festgelegte Asterisk-Benutzer dort auch tatsächlich Schreibrechte hat. Direkt nach dem Aufruf des Binaries überprüft die Start-Funktion mittels »monitor « nochmals, ob der Start auch tatsächlich funktioniert hat und Asterisk so läuft, wie gewünscht. Von der Astcanary-Episode abgesehen ist die verwendete Start-Funktion eine typische, wie sie mit leichten Anpassungen auch für viele andere Daemons zum Einsatz kommen könnte. Die gesamte Start-Funktion sieht aus, wie in Listing 9.

Listing 9

Die Start-Funktion

 

Die Stop-Funktion

Sinn und Zweck der Stop-Funktion ist es, sicher zu wissen, dass Asterisk im Anschluss an den Agent-Aufruf nicht mehr läuft. Am Anfang der Funktion steht wiederum ein Aufruf von »monitor« , der »OCF_SUCCESS« zurückgibt, wenn Asterisk bereits abgeschaltet ist. Danach kommt ein viergliedriges Schema zum Einsatz: Erst bekommt Asterisk mittels »core stop now« -Befehl über die Asterisk-Shell den Befehl zum Beenden. Das sollte im Normalfall reichen. Tut es das nicht, folgt ein Kill mit »SIGTERM« . Sollte dieser Befehl nicht den Rückgabewert 0 liefern, so bedeutet das, dass der Kill-Befehl gar nicht erst seine Arbeit verrichten konnte und der Daemon das Signal nie erhalten hat; der Agent steigt an dieser Stelle mit »OCF_ERR_GENERIC« aus, denn es ist wahrscheinlich, dass das System in gröberen Schwierigkeiten steckt. Wenn »kill -s TERM« keine Fehlermeldung zurückgibt, bedeutet das allerdings nicht, dass der Prozess auch tatsächlich stirbt. Der Agent überprüft das und schickt gegebenenfalls noch ein »SIGKILL« nach – solange, bis der Wert für den Timeout der Stop-Funktion erreicht ist. Läuft der Daemon danach noch immer, ist manuelles Eingreifen seitens des Admins notwendig. Insgesamt kann die »asterisk_stop« -Funktion aussehen, wie in Listing 10.

Listing 10

Die asterisk_stop-Funktion

 

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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 /2021