Taula de continguts:

Script de supervisió del servei per a servidors Linux: 4 passos
Script de supervisió del servei per a servidors Linux: 4 passos

Vídeo: Script de supervisió del servei per a servidors Linux: 4 passos

Vídeo: Script de supervisió del servei per a servidors Linux: 4 passos
Vídeo: Beelink GK Mini часть 2 - Autoboot, Debian 11, Supervised Home Assistant 2024, De novembre
Anonim
Script de supervisió del servei per a servidors Linux
Script de supervisió del servei per a servidors Linux

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: