Newsgroup: it.comp.os.linux.sys
Titolo: Mantenere servizi up

Dunque ci sono alcuni demoni che devono restare su sempre e comunque 
naturalmente, ad esempio openvpn e slapd.
Ora qual è la strategia per non trovarli mai down??
Un restart in cron non mi sembra molto astuto, anche perché se un demone 
  muore da solo un motivo ci sarà, e mica è detto che ripartirebbe.
Ancora non ho provato ma mi sembra invece che si potrebbe usare zabbix, 
metto un trigger su quel demone e se down mi avverte della cosa e prova 
da solo a ritirarlo su.
Peccato che non sono ancora riuscito a far andare la notifica, ma 
dovrebbe essere un problema semplice.
Ci sono altre utility fatte apposta per questa necessità?

 Ci sono altre utility fatte apposta per questa necessità?
init?
Bye.

Alessandro Pellizzari ha scritto:

E come dovrei usarlo init per fare quello che ho scritto scusa?

 E come dovrei usarlo init per fare quello che ho scritto scusa?
Modifichi inittab perche` a un certo runlevel avvii (in respawn) il tuo 
daemon (senza mandarlo in bg), o uno script che avvia il daemon e lo 
monitora.
E` grezzo, ma si arrangia a riavviare i processi che muoiono.
Bye.

 Bye.
O usare daemontools di djb, che e' stato pensato per quello.

buzzz ha scritto:

Ho provato ad installare i daemon tools, e anche se mi sembrano molto 
potenti se non ho capito male devo riscrivermi tutti i servizi, e non è 
che frema dalla voglia di farlo.
Inoltre ubuntu usa upstart, che magari mi dà già alcune di queste features..
Ma zabbix non va proprio bene per questo lavoro?

 
Sì sono d'accordo, infatti io voglio comunque essere avvertito 
tempestivamente perché è chiaro che qualcosa non va se un demone va giù, 
però appunto mi domandavo quale fosse il modo migliore.

 Ora qual è la strategia per non trovarli mai down??
I riti esoterici del mago Otelma :)
Oppure:
a) un sistema di monitoraggio dei fallimenti hardware, che faccia si' che
appena un (sotto) componente comincia ad uscire dalle specifiche ci sia una
comunicazione, per intervenire proattivamente;
b) un sistema di gestione e riavvio dei software;
c) un insieme di procedure organizzative per far si' che ci sia sempre
qualcuno che, a seguito degli output di a) e b), sappia cosa fare.
Per a), la soluzione tipica e' a livello SNMP, quindi puo' essere Nagios,
OpenNMS, Zabbix. Puo' essere molto impegnativo da configurare, e richiede di
avere hardware che sia in grado di diagnosticarsi un po'.
Per b), un sistema come Monit e' quasi sufficiente, anche se e' molto
processo-centrico quindi puo' fare sostanzialmente solo un restart (non
compulsivo). Sicuramente lo configuri in minuti/ore.
C) dipende dal tuo ambiente, non e' una questione di software ma
organizzativa, ma non va sottovalutata.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 'watchdog' per riavviare servizi in caso morte improvvisa.
in questo caso uso talvolta uno scriptino tipo questo sotto, limitato ma 
spesso molto utile - con notifiche via email/sms/ecc...
===
#!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
# elenco dei nomi dei processi da controllare col ps
aServices=(
	# esempi
	'httpd'
	'smbd'
	'my_daemon'
)
# indirizzo email per le notifiche
toAddr="noti...@tuodominio.ext"
serverName=$(uname -n)
footerMsg="Buona giornata.\n\n-- \n'$(basename $0)' su ${serverName}"
# eventuali funzioni di riavvio processi; opzionali, ma
# se definite devono essere chiamate: restart_nomeprocesso
restart_httpd ()
{	service httpd restart &
}
restart_smbd ()
{	/etc/init.d/samba restart &
}
# === main ===
servDown=''
for (( i = 0, n = ${#aServices[@]} ; i < $n ; i++ ))
do
	pn=${aServices[$i]}
	(ps ax|egrep -c "\\b${pn}\\b") 2>&1 >/dev/null || \
	{	servDown="${servDown}- \"${pn}\" e' giu'"
		# e' definita la funzione restart_nomeprocesso?
		declare -F "restart_$pn" 2>&1 >/dev/null && \
		{	servDown="${servDown} (inviato restart)"
			# prova a riavviare il processo
			eval "restart_${pn}" >/dev/null 2>&1
		}
		servDown="${servDown}\n"
	}
done
# invia notifica (per esempio) via email
[ "$servDown" != '' ] && \
{	echo -e "${servDown}\n${footerMsg}" | \
		mail -s "[Alert] Servizi giu' su: ${serverName}" "$toAddr"
}
=====
ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 spesso molto utile - con notifiche via email/sms/ecc...
La configurazione di monit e' piu' breve :)


Mandi! andrea
  In chel dì si favelave...
a> Ci sono altre utility fatte apposta per questa necessità?
Io sono in una fase di blanda analisi e ricerca, ma se non ti interessa
un sistema centralizzato di monitoraggio come nagios puoi benissimo
pensare a monit.
-- 
  ...buffoni che campate di versi senza forza
  avrete soldi e gloria, ma non avete scorza;		(F. Guccini)

 
grazie a tutti delle risposte, sto guardando monit e mi pare proprio che 
abbia tutto quello che mi serve, anche se fanno lavori un po' diversi mi 
sa che eviterò pure di usare tripwire, decisamente eccessivo per le mie 
necessità.

andrea ha scritto:

Questo monit è veramente ottimo, ad esempio con questa conf
check process openvpn with pidfile /var/run/openvpn.calzitex.pid
         group openvpn
         start program = "/etc/init.d/openvpn start"
         stop  program = "/etc/init.d/openvpn stop"
         if failed port 1194 type udp then restart
         if 5 restarts within 5 cycles then timeout
openvpn buttato giù brutalmente è ripartito che è un piacere!
Lo faccio partire con upstart (init in ubuntu) in questo modo:
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
console output
exec /usr/sbin/monit -c /etc/monit/monitrc -d 180 -s 
/var/lib/monit/monit.state -I
L'unica cosa che non va è questa
monit status
monit: error connecting to the monit daemon
Eppure il demone è attivo:
ps uax | grep monit
root     13265  0.0  0.0  37564  1992 ?        Ss   10:07   0:00 
/usr/sbin/monit -c /etc/monit/monitrc -d 180 -s 
/var/lib/monit/monit.state -I