Taula de continguts:
- Pas 1: utilitzar els mètodes proporcionats per Systemd
- Pas 2: Configuració i ús dels scripts de comprovació de serveis
- Pas 3: Pensaments finals
Vídeo: Script de supervisió del servei per a servidors Linux: 4 passos
2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:16
Tenir un sistema estable i sempre en execució, fins i tot si utilitzeu Linux, pot ser una tasca difícil.
A causa de la complexitat dels paquets de programari moderns i la mala codificació, inevitablement alguns processos poden fallar de tant en tant. Això podria ser dolent si esteu executant un servidor i algunes persones confien en aquests serveis.
Pas 1: utilitzar els mètodes proporcionats per Systemd
Com ja sabreu, la majoria dels sistemes operatius Linux moderns utilitzen systemd.
Si no esteu familiaritzat amb systemd, això és, segons la viquipèdia:
"… un sistema d'inici utilitzat en distribucions Linux per arrencar l'espai de l'usuari i gestionar tots els processos posteriorment, en lloc dels sistemes d'inici UNIX System V o Berkeley Software Distribution (BSD). …"
Molta gent encara discuteix per què era necessari substituir el bon sistema d'inici antic per aquest sistema de gestió de processos més complicat, però al següent enllaç es pot trobar una bona explicació:
www.tecmint.com/systemd-replaces-init-in-l…
La millora més important seria que és capaç d’iniciar el sistema més ràpid que init, a causa del processament simultani i paral·lel a l’arrencada en lloc de l’enfocament seqüencial d’init
Sense entrar en el fons de systemd, per afegir un procés al systemd, heu de crear un fitxer de servei. La sintaxi d’aquest fitxer pot anar des de molt simple fins a completament complicada i no entrarem en detalls. Per tenir un fitxer.service bàsic, és suficient utilitzar les entrades següents:
[Unitat] Descripció = Descripció de l’aplicacióDocumentació = https://wikipedia.org/ After = local-fs.target network.target [Servei] Tipus = simpleExecStart = / usr / sbin / applicationExecReload = / usr / sbin / application reloadExecStop = / usr / sbin / application stopRestart = sempre [Instal·la] WantedBy = multi-usuari.target
Col·loqueu-los al fitxer application.service a la carpeta / lib / systemd / system.
El que fan cadascuna d’aquestes opcions s’explica al següent enllaç:
access.redhat.com/documentation/en-US/Red_…
Per començar l’aplicació, emeteu l’ordre següent:
sudo systemctl iniciar application.service
Nota: l'extensió.service es pot ometre.
Per aturar l'aplicació:
sudo systemctl stop application.service
Si s'ha canviat el fitxer de configuració i voleu tornar a carregar la configuració:
sudo systemctl recarrega application.service
Per reiniciar l'aplicació:
sudo systemctl reinicieu application.service
Per activar l'inici automàtic a l'arrencada:
sudo systemctl habilita application.service
Si està activat, el gestor de processos del sistema intentarà iniciar l'aplicació en funció de la configuració proporcionada pel fitxer del sistema.
Per desactivar-lo, utilitzeu la mateixa ordre anterior, però amb el paràmetre "disable".
Si col·loqueu Reinicia = sempre al fitxer de servei, systemd supervisarà el procés i, si no es troba a la llista de processos, intentarà reiniciar-lo automàticament.
Si col·loques
RestartSec = 30
després de la directiva de reinici, esperarà 30 segons abans d'intentar reiniciar el procés. Això pot ser útil, ja que un intent de reinici continu d'un servei o aplicació que falla pot generar una gran demanda del sistema (escriure registres d'errors, etc.)
Com podeu veure, systemd ja proporciona alguns mitjans per controlar els processos. No obstant això, en alguns casos això pot no ser suficient. Què passa si un procés no surt (encara estarà a la llista de processos), però deixa de respondre. En aquest cas, per assegurar-vos que un procés està en funcionament, és possible que necessiteu verificacions addicionals.
Aquí és on seran útils els guions d’aquest instructiu.
Pas 2: Configuració i ús dels scripts de comprovació de serveis
Si necessiteu més control dels vostres processos / serveis en execució, aquests scripts us seran útils, segur.
Com que el codi és una mica gran, es penja a github i es pot trobar al següent dipòsit:
github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh
El "cor" de tot el paquet és el
checkService.sh
Abans d’utilitzar-lo, heu de substituir el camí complet de la carpeta de serveis. Es pot trobar al principi del guió.
El script pot supervisar diversos processos i realitzar tasques addicionals, tal com es descriu a continuació:
Revisa cada fitxer de la subcarpeta / services que té extensions.serv o.check i comprovarà si hi ha un procés actiu anomenat "aplicació".
Si no hi ha cap fitxer ".check" per a una aplicació, només el fitxer application.serv:
Si el procés està actiu, el considerarà actiu
Si el procés està inactiu, reiniciarà el servei emetent l'ordre següent:
reinicia l'aplicació systemctl
si el fitxer.serv està buit!
Si el fitxer.serv no està buit i té drets executables, intentarà executar-lo com a script BASH senzill.
Això és útil si cal fer alguna cosa addicional a més de reiniciar el servei.
Per exemple, al fitxer spamd.serv, de la reposició anterior, en cas que el servei spamd estigui mort, cal reiniciar el servei spamassassin, que també reiniciarà spamd. Reiniciar només spamd no seria suficient.
Es pot editar el contingut d’aquest fitxer de serv segons les necessitats.
Un altre exemple és el fitxer pcscd.serv. En aquest cas també es van reiniciar / matar diversos altres processos.
Si hi ha un fitxer de comprovació, després de comprovar si el procés s’executa, també executarà aquest fitxer de script per realitzar comprovacions addicionals.
Per exemple, per al servei oscam, hem creat un fitxer de comprovació que intenta connectar-se a la seva interfície web per veure si té èxit. Si no és així, tot i tenir el procés actiu, el servei no respon i cal reiniciar-lo. El reinici del servei ha de ser realitzat / cridat pel propi fitxer.check.
Un altre exemple seria el servei DLNA de mediatomba.
Es tracta d’un servidor petit que proporciona contingut de vídeo / àudio als clients DLNA i s’emet a la xarxa. De vegades el servei es penja i ja no es pot descobrir, però el procés continuarà actiu. Per comprovar si el servei es pot descobrir, s'ha utilitzat la utilitat CLI anomenada gssdp-discover. Tot el codi que comprova el servidor DLNA es va col·locar dins d'un script mediatomb.check.
Aquests són només alguns exemples sobre com podeu utilitzar els fitxers.serv i.check.
Per tal de supervisar un nou servei, heu de crear un fitxer.serv i, si cal, també un fitxer de comprovació i escriure-hi el script corresponent.
Si només es comprova la presència del procés, és suficient un fitxer.serv buit. Si s’han de fer comprovacions addicionals, s’ha de crear un fitxer.check i s’ha d’escriure un petit script per fer la feina.
Per descomptat, l'script.sh s'ha d'executar periòdicament, per tant, també s'ha de crear un treball cron per a això:
#check serveis en execució cada 5 minuts * / 5 * * * * /var/bin/ServiceCheck/checkService.sh> / dev / null
Pas 3: Pensaments finals
Espero que trobeu útil aquest paquet, ja que pot simplificar la supervisió dels processos de Linux i espero que minimitzi el temps d'inactivitat dels vostres serveis.
Si en creeu de nous, podeu penjar scripts addicionals a github. Feu-m'ho saber i us afegiré com a col·laborador.
Recomanat:
E.S.D.U (Unitat de droides del servei d’emergències): 7 passos
E.S.D.U (Unitat de droides del servei d’emergències): Avui construirem una E.S.D.U (Unitat de droides del servei d’emergències). La E.S.D.U es divideix en 3 classes: Policia, Bombers i Medic. Tot això encara no està completament desenvolupat, però espero que puguem actualitzar-los i desenvolupar-los junts com a com
UChip: esbós senzill per a motors i / o servidors de control remot mitjançant ràdio Tx-Rx a 2,4 GHz !: 3 passos
UChip: esbós senzill per a motors i / o servidors de control remot mitjançant ràdio Tx-Rx a 2,4 GHz !: M'agrada molt el món de RC. L'ús d'una joguina RC us dóna la sensació que teniu el control d'alguna cosa extraordinària, tot i ser un vaixell petit, un cotxe o un dron. Tot i això, no és fàcil personalitzar les vostres joguines i fer-les fer el que vulgueu
Rellotge de paraules controlat per 114 servidors: 14 passos (amb imatges)
Rellotge de paraules controlat per 114 servidors: què té 114 LED i sempre s’executa? Com sabreu, la resposta és un rellotge de paraules. Què té 114 LED + 114 servos i sempre es mou? La resposta és aquest rellotge de paraules servo-controlat. Per a aquest projecte, em vaig associar amb un amic meu que va convertir
Automatització i supervisió domèstica controlats per veu / Internet mitjançant ESP8266 i Google Home Mini: 6 passos
Automatització i control domèstic domèstic de veu / Internet controlats mitjançant ESP8266 i Google Home Mini: Ei! Després d’un llarg descans estic aquí, ja que tots hem de fer alguna cosa avorrida (feina) per guanyar. Després de tots els articles d’HOME AUTOMATION que he escrit de BLUETOOTH, IR, WIFI local, Cloud, és a dir, els difícils, * ARA * ve el més fàcil però el més eficient
Supervisió en directe del valor del sensor des de qualsevol lloc del món: 4 passos
Supervisió en directe del valor del vostre sensor des de qualsevol lloc del món: em va aparèixer un missatge sobre el número de WhatsApp de techiesms sobre ajuda per fer un projecte. El projecte consistia a mesurar la pressió exercida sobre el sensor de pressió i mostrar-la al telèfon intel·ligent. Així que vaig ajudar a fer aquest projecte i vaig decidir formar un tutor