Hi,
enterprise 1.6.0p12
Ich habe auf meinen Linux-Maschinen den Systemd Service check laufen. Auf einem Debian 9 host ist dieser check jetzt critical geworden
CRIT - 85 services in total, 1 static service failed (check-mk-agent@8-###:6556-###:64073)
Der check-mk-agent funktioniert einwandfrei und das ist ja gar kein Service, den ich neu starten könnte… wie geht man denn das an, bitte?
Hi Joker,
ich habe hier einen Werk gefunden, der dir eventuell weiterhelfen könnte.
Hast du den check_mk_agent über systemd oder xinetd am Laufen?
Grüße
Anastasios
Gute Frage! Ich ruf den Agent per ssh auf.
Wo sehe ich, ob ich systemd oder xinetd für den check_mk_agent verwende?
Das Werk hört sich genau nach meinem Thema an, aber ich bin auf 1.6.0p12, da sollte das doch schon behoben sein.
Wenn du auf dem zu überwachenden Host ein systemctl --all absetzt, siehst du den check_mk_agent?
Dann verwendest den Agent weder mittels systemd noch xinetd 
Andere Frage hast den Agent per Paketmanager installiert oder nur Script kopiert?
Bei Aufruf per SSH sind die eingerichteten Services welche der Paketmanager mit anlegt völlig sinnfrei.
So ein Service scheint sich bei dir da zu melden.
Ja, da ist er drin, markiert als loaded, failed, failed.
Aber wie gesagt, ruf ich den Agent per ssh auf
Den Agent hab ich per Paket aus der Bakery installiert.
Wie geht man mit solchen Services um? Kann man die dauerhaft los werden?
Oder wenigstens: wie bekomme ich den Service wieder auf ok? Bei logwatch bspw reicht in einem ähnlichen Fall
service logwatch reload
auch ziemlich sinnbefreit, aber geht wenigstens. Bei dem check_mk Pseudo-Service geht das nicht.
Bin ein Stück weiter… mit Hilfe einer Anleitung, den check_mk Agent unter systemd zum Laufen zu kriegen How to install and configure check mk agent using systemd on ubuntu | wachid web id habe ich ein paar Spuren entdeckt…
unter /etc/systemd/system habe ich Spuren:
ls -l /etc/systemd/system/check-mk-agent*
-rw-r–r-- 1 root root 401 May 30 17:18 /etc/systemd/system/check-mk-agent@.service
-rw-r–r-- 1 root root 305 May 30 17:18 /etc/systemd/system/check-mk-agent.socket
Den Socket-Service kann ich (unnötigerweise, da ssh) abrufen, aber nicht den @-Service
systemctl status check-mk-agent.socket
● check-mk-agent.socket - CheckMK Agent Socket
Loaded: loaded (/etc/systemd/system/check-mk-agent.socket; enabled; vendor preset: enabled)
Active: active (listening) since Fri 2020-05-29 03:17:20 CEST; 1 weeks 3 days ago
Listen: [::]:6556 (Stream)
Accepted: 10; Connected: 0;
Tasks: 0 (limit: 2300)
Memory: 44.0K
CGroup: /system.slice/check-mk-agent.socketWarning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
systemctl status check-mk-agent@
Failed to get properties: Unit name check-mk-agent@.service is neither a valid invocation ID nor unit name.
Mhmm… und nun?
Vielleicht löscht du einfach die zwei Dateien?
Vielleicht erst eine Stufe “sanfter” versuchen.
systemctl disable check-mk-agent.socket
Gruß
Martin
Würde auch zu @martin.schwarz seiner Variante tendieren. Das Problem ist es hier eher falls du den Agent Updater benutzten willst wird der Service im schlimmsten Fall bei jedem Update wieder aktiviert.
Das kann ich gerade nicht aus dem Kopf sagen. Falls kein Agent Updater verwendet werden soll ist das Problem mit dem Deaktivieren des Service erledigt.
@andreas-doehler, @martin.schwarz, @athomaidis
an das Löschen hab ich auch schon gedacht, aber da ich den agent über die Bakery ausrolle, würde ich auch damit rechnen, dass das beim nächsten update wieder da ist.
check-mk-agent.socket macht kein Problem, die habe ich schon mit
system stop check-mk-agent
system diable check-mk-agent
weg bekommen. Aber der check-mk-agent@.service will nicht reagieren.
systemctl disable check-mk-agent@
gibt keine Ausgabe… aber
systemctl status check-mk-agent@
Failed to get properties: Unit name check-mk-agent@.service is neither a valid invocation ID nor unit name.
Und in
systemctl --all
ist er immer noch drin als loaded, failed, failed
In deinem Beispiel war der Socket aber (wieder?) aktiviert:
systemctl status check-mk-agent.socket
● check-mk-agent.socket - CheckMK Agent Socket
Loaded: loaded (/etc/systemd/system/check-mk-agent.socket; enabled; vendor preset: enabled)
Mit meinem systemd-Halbwissen: Das “check-mk-agent@.service” ist eine Template Unit, als “Vorlage” eine “on-demand” Instanz des Agents - bei Zugriff auf den Socket. Ich würde erwarten, dass ohne aktiven Socket auch ger nicht erst versucht wird, daraus einen Agent zu starten.
Klappt ein systemctl reset-failed check-mk-agent@.service? Sonst halt mit systemctl reset-failed gleich alle fehlgeschlagenen Services - waren lautdem ersten Post ja auch keine weiteren. Damit sollte der akut gemeldet CRIT-Zustand erstmal bereinigt sein. Und eben den Socket deaktivieren, damit es nicht wieder auftaucht (sofern nicht ein Agent-Update den Socket von selbst wieder aktiviert, da bin ich mir nicht sicher).
Gruß
Martin
Fast! Die Template Unit reagiert nicht, aber die konkrete Instanz mit den IP-Adressen, wie man sie aus
systemctl
bekommt, reagiert:
Loaded: loaded (/etc/systemd/system/check-mk-agent@.service; static; vendor preset: enabled)
Active: inactive (dead)
Hört sich zwar auch nicht ganz überzeugend an, aber im Monitoring ist der Crit-Status jetzt wieder weg, der Service scheint auch nicht mehr aktiv zu sein (trotz “loaded”)
Vielen Dank euch allen!
Tja… wie dz schon befürchtet hast, mit einem Agent-Update ist der Socket wieder da…
cmk-update-agent -v
…
Warning/Error from dpkg:
Created symlink /etc/systemd/system/sockets.target.wants/check-mk-agent.socket → /etc/systemd/system/check-mk-agent.socket.
Gibt es denn keine Möglichkeit, im Wato oder der Bakery den Agents Systemd komplett auzutreiben? Wenn man doch eh ssh oder was anderes will?
Ich hab jetzt noch einen Workaround vom November gefunden - einen Filter Systemd Service Summary - #14 by MatthewStier
Go to ‘WATO - Configuration’; ‘Host & Service Parameters’; Search for ‘systemd’; Select ‘Systemd Services’; and add a filter for ‘check_mk@*’
Aber das ist halt nur ein Workaround und löst nicht das (neue) Problem der unnötigen Sockets.
Kurz noch eine Meinung von mir.
So lange der Service nie per Systemd aufgerufen wird darf auch die Service Instanz nie in einen Failed State gehen.
Der Socket selbst ist halt trotzdem vorhanden was natürlich unschön ist sobald das Security Team wieder mal ein Audit macht 
korrekt. Tut sie aber leider… und Werk #10710 systemd: Do not mark the agent unit failed on single agent failure das das Verhalten beheben sollte, tut scheinbar auch nicht…
Das mit der Security ist halt leider auch wahr 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.