Hi,
wir verwenden die 2.0.0p18 cee. Ich habe eine Frage zum Starten und Stoppen von Sites. Gibt es da einen bevorzugten Weg? Wir haben bisher immer über su - und dann omd stop/start eine Site verwaltet. Man kann das Ganze bei Rhel7/8 ja auch über systemctl steuern. Gibt es da Unterschiede / Vor-Nachteile? Woher weiß systemctl denn, welche Site er stoppen/starten soll, wenn es mehrere gibt?
Danke vorab!
Christian
Hallo Christian,
Mir ist nur der Weg über omd bekannt. In systemd ist auch nur eine Teil als unit zu sehen:
[root@wweasmon0007 ~]# systemctl list-units | grep omd
opt-omd-sites-preprod-tmp.mount loaded active mounted /opt/omd/sites/preprod/tmp
opt-omd-sites-test-tmp.mount loaded active mounted /opt/omd/sites/test/tmp
omd.service loaded active exited Check_MK Monitoring
Meine Empfehlung lautet daher nimm omd zum starten/stoppen Deiner sites.
Gruß
Michael
Du musst nicht zwangsweise ein su in den Site-User machen. Du kannst auch als root “omd start|stop ” machen. Als root “omd status” listet Dir den Status aller Sites mit allen ihren Diensten auf.
Hi @mike1098 ,
danke schon mal für den Input. Wie macht ihr das dann, wenn der cmk-Server rebootet? Bei uns startet derzeit systemctl den omd.service automatisch. Habt ihr dann eigene Systemd-Services geschrieben und startet darüber automatisch?
VG
Christian
Hallo Christian,
Darüber hatte ich mir nie Gedanken gemacht.
Ich gehe davon aus dass der omd.service sich darum kümmert das ALLE sites ordentlich runter gefahren bzw. gestartet werde. Zumindest hatten wir bisher nie Schwierigkeiten damit.
Ich habe das gerade mal eben auf meiner Bastelumgebung getestet und nach einem systemctl stop omd sind alle sites gestoppt.
Nach einem systemctl start omd sind auch alle sites wieder oben.
Wenn ich jetzt da nix total mißverstanden habe dann sehe ich da keinen Grund sich selbst etwas zu Stricken.
Gruß
Michael
Im Grunde hast du Recht. Was aber zumindest bei uns etwas unschön ist, wenn ich per omd stop/start eine Site steuere, weiß systemctl im Anschluss nicht mehr, ob die Site läuft oder nicht. Also wenn ich einmal omd stop bei einer Site mache, ist danach systemctl status nicht mehr nutzbar. Das hatte uns jetzt ein wenig verunsichert. Aber wir lassen das erst so mal wie es ist, d.h. der omd.service steuert beim Reboot das Stoppen und Starten aller Sites und wenn wir einzelne Sites verwalten wollen, nehmen wir weiterhin das omd-Kommando.
VG
Kannst Du mal zeigen wie das aussieht?
Zumindest unter CentOS7 hat das Stoppen oder Starten einer site bei mir keinen Einfluß auf den omd service.
Gruß
Michael
Das ist auch soweit richtig, nur mit dem Unterschied was @CFriedrich meint der systemctl weiß dann nicht mehr welche Prozesse zu dem Service gehören. Hier sollte man eigentlich besser sagen.
Wenn der OMD Service per systemctl gesteuert wird und man will, dass das System auch Bescheid weiß was zum Service gehört dann darf kein “omd stop” und “omd start” mehr verwendet werden.
Hier stellt sich dann nur noch das Problem, dass immer nur alle Sites eines Servers gestoppt und gestartet werden können mittels systemctl.
systemctl status omd - mit ordentlich gestartetem Service
omd.service - Checkmk Monitoring
Loaded: loaded (/etc/systemd/system/omd.service; enabled; vendor preset: enabled)
Active: active (exited) since Fri 2022-07-08 23:07:30 CEST; 2 days ago
Docs: https://docs.checkmk.com/latest/en/
Main PID: 736063 (code=exited, status=0/SUCCESS)
Tasks: 51 (limit: 37749)
Memory: 1.1G
CPU: 3h 16min 1.838s
CGroup: /system.slice/omd.service
|- 736072 python3 /omd/sites/home/bin/gunicorn -D -p /omd/sites/home/tmp/run/agent-receiver.pid --error-logfile /omd/sites/home/var/log/>
|- 736076 python3 /omd/sites/home/bin/gunicorn -D -p /omd/sites/home/tmp/run/agent-receiver.pid --error-logfile /omd/sites/home/var/log/>
|- 736078 python3 /omd/sites/home/bin/mkeventd --syslog --syslog-fd 3 --syslog-tcp --syslog-tcp-fd 4 --snmptrap --snmptrap-fd 5
|- 736087 python3 /omd/sites/home/bin/liveproxyd
|- 736099 python3 /omd/sites/home/bin/mknotifyd
.......
Und so siehts aus wenn zwischendrin mal ein “omd stop” + “omd start” erfolgte.
* omd.service - Checkmk Monitoring
Loaded: loaded (/etc/systemd/system/omd.service; enabled; vendor preset: enabled)
Active: active (exited) since Fri 2022-07-08 23:07:30 CEST; 2 days ago
Docs: https://docs.checkmk.com/latest/en/
Main PID: 736063 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 37749)
Memory: 119.5M
CPU: 3h 16min 4.951s
CGroup: /system.slice/omd.service
Jul 08 23:07:21 monitoring omd[736088]: Starting mknotifyd...OK
Jul 08 23:07:21 monitoring omd[736100]: Starting rrdcached...OK
Keine Prozesse mehr welche hierzu gehören.
Danke @andreas-doehler , ich war gerade auch dabei den Output zu erstellen 
Nach einiger Zeit springt bei uns dann noch die Active Zeile von active auf inactive:
# systemctl status omd
● omd.service - Checkmk Monitoring
Loaded: loaded (/etc/systemd/system/omd.service; enabled; vendor preset: disabled)
Active: inactive (dead)
Docs: https://docs.checkmk.com/latest/en/
VG
Wenn das laut systemd Spezifikation so sein muss, dann wäre das ja ein Bug den man melden sollte.
Mir ist das nie aufgefallen da ich immer omd benutze um Sites bzw. deren Services zu stoppen/starten.
Wenn dass komplett ins systemd abgebildet werden muss, hätte man dann ja pro site mindestens 10 einzelne Units. Zumindest wäre mir nicht bekannt das systwemctl eine option hat mit der man einzelne Prozesse einer Unti stoppen/starten kann. Ich weis aber auch nicht alles 
Gruß
Michael
Also wenn mal einen Blick in das Unit File riskiert, dann tut das auch nur einen omd start bzw. omd stop:
[Unit]
Description=Checkmk Monitoring
Documentation=https://docs.checkmk.com/latest/en/
Wants=network-online.target
After=syslog.target time-sync.target network.target network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/omd start
ExecStop=/usr/bin/omd stop
ExecReload=/usr/bin/omd reload
[Install]
WantedBy=multi-user.target
Ich denke der Service is rein dazu gedacht die sites beim Starten des OS zu starten und beim herunterfahren zu stoppen.
Gruß
Michael
Zunächst muss man wissen, dass alle Sites ein Attribut AUTOSTART haben, das in der Voreinstellung auf on steht. Man kann das beim Erstellen einer Site ändern:
# als root:
omd create --no-autostart testsite
oder auch nachträglich:
# prüfen als root:
omd config testsite show AUTOSTART
on
# setzen als root:
omd config testsite set AUTOSTART off
Wenn man nun als root nur omd start oder omd stop sagt, dann werden alle Sites gestartet, bei denen AUTOSTART=on ist.
Will man nur bestimmte Sites starten, sagt man entweder als root omd start testsite bzw. omd stop testsite oder führt die Befehl als Site-Nutzer aus: su - testsite; omd start; omd stop.
Die systemd-Unit omd.service hat im Grunde nur den Zweck, beim Booten als root omd start auszuführen, d.h. alle Sites mit AUTOSTART=on zu starten. Beim Herunterfahren wird entsprechend omd stop ausgeführt. Wenn man nun manuell alle Sites starten oder stoppen will, kann man das also über systemctl-Befehle machen, aber so ist es nicht gedacht. Vorgesehen ist, dass man die omd-Befehle verwendet.
Unabhängig vom AUTOSTART-Attribut werden Sites, die disabled sind, bei diesen „Gießkannen-Operationen“ ebenfalls ignoriert. Für solche Sites wird aber zusätzlich noch die sitespezifische Konfiguration des systemweiten Apache entfernt, so dass bei Aufruf der Webseite nicht Site not started sondern 404 Not Found erscheint.
Im Großen und Ganzen: Was @Dirk sagt. Tolle Zusammenfassung!
Es gibt andere Systeme, wie Gitlab, die auch so arbeiten. Dort gibt es verschiedene Komponenten, die innerhalb der Software verwaltet werden und von denen systemd nichts weiß.
Bei Checkmk kann man es so herunterbrechen: systemd weiß nichts vom Status der Sites. Wie @Dirk das völlig richtig erklärt hat, ist der omd.service nur ein Helferlein. Die wahre Kontrolle steckt im omd Befehl.
TL;DR: Nutzt für das Site-Management nur den omd Befehl! systemd spielt hier nicht mit.
Hallo,
kann es sein das im Zusammenhang mit Pacemaker man das gleiche Problem hat? Hab gestern beobachtet wie omd zwar immer korrekt ausgibt welche Instanz läuft und welche nicht, aber systemd bekommt es nicht mit und pacemaker dann auch nicht.
Das wäre ein plausible Erklärung oder?
Dachte bisher das liegt am OCF Agent, dass der fehlerhaft ist, aber ja dann vielleicht doch nicht. Wir nutzen aktuell die Appliance, haben aber die Ansage das wir auf CentOS umstellen müssen. 
Beobachtung betrifft demnach CentOS 8.
Kann schon sein. Kommt drauf an, wie Pacemaker und checkmk “gekoppelt” sind. Ich habe mal eine Seite betreut, bei der checkmk mit Pacemaker gesteuert wird. Die Site haben wir auf AUTOSTART=off gestellt, weil sie ja nicht automatisch starten soll, sondern duch Pacemaker. Die systemd-Unit omd.service haben wir ignoriert, d.h. auf enabled gelassen. Die Unit startet dann zwar beim Booten, aber macht nichts.
Für die Steuerung der Site habe ich einen Resource Agent geschrieben, der site-spezifisch mit den Befehlen omd start/stop/status arbeitet.
Ich weiß nicht, wie die Appliance das macht. Ob Pacemaker da systemctl status macht oder omd status. Ersteres wäre wenig aussagekräftig, weil es nur zeigt, ob der Befehl omd start erfolgreich war, was i.d.R. der Fall ist. Und bei letzterem muss man sich überlegen, was passieren soll, wenn die Site nur teilweise läuft (z.B. wenn der mknotifyd nicht läuft).
Hallo Dirk,
genau das habe ich ja auch vor. Pacemaker steuert omd, Autostart=off.
Die Appliance ist das was wir aktuell nutzen, daher brauchte ich mich mit dem Thema bisher nicht beschäftigen. Nun müssen wir “umbauen” auf eine eigene Lösung. Alle Überlegungen betreffen nicht die Aplliance!
Auf CentOS seh ich den Effekt das systemd glaubt die jeweiligen Dienste laufen nicht, tun sie aber doch. Und Pacemaker weiß bei einem Node standby/unstandby oder auch move teilweise auch nicht ob omd läuft oder eben nicht.
Da meinst du aber, dass kann wiederum nicht am systemd liegen sondern nur am Agenten? Der liest ja omd aus und sagt dem pacemaker was Sache ist, oder? Da spielt das systemd dann in dem Sinne keine Rolle? Dachte das ist vielleicht eine Erkläung hier im Thread für meine Baustelle.
Danke
Wie gesagt, ich habe die systemd-Unit komplett ignoriert. Sie wird bei uns auch nicht von Pacemaker überwacht oder gesteuert. Wir steuern die Site nur über einen eigenen Resource-Agent, der mit omd-Befehlen arbeitet. Damit kriegt man das schon geregelt. Ein Problem, das wir hatten: Wenn die Site etwas unter Wasser ist, kann der Befehl omd status etwas dauern und Pacemaker verliert die Geduld (sprich: schießt den Knoten weg). Da muss man dann die Timeouts entsprechend setzen. Aber das sprengt jetzt etwas den Rahmen dieses Threads.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.