{"id":20,"date":"2007-04-10T15:59:24","date_gmt":"2007-04-10T13:59:24","guid":{"rendered":"http:\/\/www.instruyete.org\/?p=20"},"modified":"2007-04-10T15:59:24","modified_gmt":"2007-04-10T13:59:24","slug":"daemon-handling-unter-solaris-10","status":"publish","type":"post","link":"https:\/\/www.instruyete.org\/?p=20","title":{"rendered":"daemon handling unter Solaris 10"},"content":{"rendered":"

In der klassischen System V Welt, d.h. auch unter Linux aber nicht unter Mac OS X, gibt es verschiedene Runlevels zu denen es jeweils ein Unterverzeichnis unterhalb \/etc gibt mit Start- und Stopscripten von Diensten.
\nStartet also der init Prozess (pid 1) auf einem System V UNIX System arbeitet er sukzessive die Startskripte dieser Verzeichnisse ab, wobei zumindest unter Linux einen Nummerierung der Startskripte die Reihenfolge der Abarbeitung festlegt.
\nEin nachtr\u00e4glicher Neustart oder das Stoppen ist jederzeit mit solch einem Skript m\u00f6glich.<\/p>\n

Dieses Konzept hat aber mindestens zwei Schwachstellen.<\/p>\n

    \n
  1. Das einf\u00fcgen eines neuen Dienstes ist aufw\u00e4ndig. Neben dem allg. Start-\/Stopskript muss in jedem passenden runlevel Unterverzeichnis ein link gesetzt werden, wobei die Nummerierung oftmals nicht eindeutig sein kann.<\/li>\n
  2. Es gibt keinen Supervisor \u00fcber die Dienste der im Fehlerfall eine Aktion ausl\u00f6sen k\u00f6nnte. Normalerweise wird lediglich im log Bereich protokolliert. Eine respawn Direktive kann diese Situation noch leicht verbessern.<\/li>\n<\/ol>\n

    Sun f\u00fchrte deshalb die sog. Service Management Facility (SMF)<\/strong> ein:
    \nDie Skripte der SMF basieren auf XML und l\u00f6sen die \/etc\/init.d Skripte ab.
    \nEin Starten (enable) oder Stoppen (disablen) eines Dienstes ist persistent, es \u00fcberlebt einen reboot des Systems. Daher ist ein seperater Eintrag in einer inittab\/runlevel obsolet.
    \nAlle so gestarteten Dienste werden von einer Art Service Masterdaemon \u00fcberwacht, dem Holderprozess svc.startd<\/strong> . Die Basis hierf\u00fcr ist ein Contract System bei der ein zu startender Dienst nebem einer klassischen PID auch eine Contract ID (CTID)<\/strong> bekommt, die direkt dem Holder Proze\u00df unterstellt ist.
    \nAuch D\u00e4monen die von inetd gestartet werden, besitzen einen SMF Eintrag und werden wie ein stand-alone Dienst gestartet – der Prozess Holder ist dann allerdings inetd, der wiedersum svc.startd untersteht.
    \nAlle Laufzeitinformationen werden in einer sqlite Datenbank gehalten, die einerseits effizient arbeitet andererseits eine m\u00f6gliche Quelle f\u00fcr einen Totalausfall des Systems darstellt.<\/p>\n

    Folgender genauerer \u00dcberblick \u00fcber die SMF:<\/strong><\/p>\n