Upstart dal sito SysAdvent

Dec 012011

Image via Wikipedia

Siamo in dicembre e per questo mese vi suggerisco di tenere un occhio sul sito: http://sysadvent.blogspot.com

Questo sito è l’equivalente per sysadmin del sito Perl Advent Calendar : Un articolo per ogni giorno del mese di dicembre, con termine al 25° articolo. Con gli obiettivi di condivisione, di apertura, ed insegnamento, gli autori hanno come obiettivo di fornire grandi articoli su argomenti di amministrazione dei sistemi scritti da altri amministratori di sistema.

Oggi vi presento uno dei loro articoli dell’ultimo anno

Questo articolo è stato scritto da Jordan Sissel (@jordansissel)

Nei sysadvents passati vi ho parlato di babysitter per servizi e ho mostrato come utilizzare supervisord. Quest’anno, Ubuntu ha iniziato fornire con la sua release un nuovo sistema di init chiamato Upstart che comprende un sistema di babysittering, quindi cercherò di parlarvi di questo. Farò tutti questi esempi su Ubuntu 10.04, ma ogni sistema che utilizzi upstard dovrebbe funzionare.

Per me, le due caratteristiche più importanti di Upstart sono il babysittering e gli eventi. Upstart supporta i semplici script che daemontools, supervisord, e altri simili strumenti supportano. Inoltre, consente di configurare dei jobs per rispondere a eventi arbitrari.

Andando più a fondo, diamo uno sguardo alla configurazione del server ssh di Ubuntu per Upstart (Ho modificato per chiarezza). Questo file sta in /etc/init/ssh.conf:

description     "OpenSSH server"

# Start when we get the 'filesystem' event, presumably once the file
# systems are mounted. Stop when shutting down.
start on filesystem
stop on runlevel S

expect fork
respawn
respawn limit 10 5
umask 022
oom never

exec /usr/sbin/sshd

Alcuni punti:

respawn – dice ad Upstart di farlo ripartire se sshd smette di funzionare in maniera anomala (il che significa che ogni uscita ad eccezione di quelle causate da voi dicendogli di fermarsi).
oom never – Fornisce un indizio all’Out-Of-Memory killer. In questo caso, diciamo di non uccidere mai questo processo. Questo è super utile come funzione integrata.
exec /usr/bin/sshd – nessun SysV init script, basta una linea che dice che binario utilizzare. Favoloso!

Nota:

Nessun comando ‘status’ scritto in maniera mediocre.
Nessuno script /bin/sh scritto in maniera mediocre
Nessun comando con la semantica confusa per dare un restart vs reload vs stop/start .

Il comando initctl(8) è l’interfaccia principale ad upstart, ma ci sono scorciatoie con status, stop, start, e restart. Vediamo lo status:

% sudo initctl status ssh
ssh start/running, process 1141

# Ma anche questo funziona (/sbin/status è un symlink a /sbin/initctl):
% sudo status ssh 
ssh start/running, process 1141

# Fermiamo il server ssh
% sudo initctl stop ssh
ssh stop/waiting

# E lo facciamo ripartire
% sudo initctl start ssh 
ssh start/running, process 28919

Onestamente, sono meno interessato a come essere un utente di upstart e più interessati a mettere dei processi in esecuzione in upstart.

Come mettiamo l’esecuzione di nagios in upstart? Creiamo /etc/init/nagios.conf:

description "Nagios"
start on filesystem
stop on runlevel S
respawn

# Run nagios
exec /usr/bin/nagios3 /etc/nagios3/nagios.cfg

Facciamolo partire:

% sudo initctl start nagios
nagios start/running, process 1207
% sudo initctl start nagios
initctl: Job is already running: nagios

Ma soprattutto, se qualcosa va storto e nagios va in crash o muore, dovrebbe riavviarsi, giusto? Vediamo:

% sudo initctl status nagios
nagios start/running, process 4825
% sudo kill 4825            
% sudo initctl status nagios
nagios start/running, process 4904

Eccellente.

Eventi

Upstart supporta messaggi semplici. Cioè, è possibile creare messaggi con ‘initctl emit [KEY=VALUE] …’ È possibile iscriversi ad un evento nella vostra configurazione, specificando ‘start on …’ e lo stesso per ‘stop’. Un esempio molto semplice:

# /etc/init/helloworld.conf
start on helloworld
exec env | logger -t helloworld

Quindi inviamo il messaggio ‘helloworld’, ma impostiamo anche alcuni parametri in questo messaggio.

% sudo initctl emit helloworld foo=bar baz=fizz

E guardate i risultati del logger (scrive su syslog)

2010-12-19T11:03:29.000+00:00 ops helloworld: UPSTART_INSTANCE=
2010-12-19T11:03:29.000+00:00 ops helloworld: foo=bar
2010-12-19T11:03:29.000+00:00 ops helloworld: baz=fizz
2010-12-19T11:03:29.000+00:00 ops helloworld: UPSTART_JOB=helloworld
2010-12-19T11:03:29.000+00:00 ops helloworld: TERM=linux
2010-12-19T11:03:29.000+00:00 ops helloworld: PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
2010-12-19T11:03:29.000+00:00 ops helloworld: UPSTART_EVENTS=helloworld
2010-12-19T11:03:29.000+00:00 ops helloworld: PWD=/

Si può anche accettare condizionatamente eventi con impostazioni chiave/valore. Vedere la manpage init(5) per maggiori dettagli.

In più, è possibile avviare dei job e passare i parametri al job con start helloworld key1=value1 ...

Problemi

Upstart ha problemi.

Primo: Debuggarlo fa schifo. Perchè il vostro script di pre-start sta fallendo? Non c’è un modo previsto di catturare l’output e la sua registrazione. La cosa migliore è fare ‘exec 2> /var/log/upstart.${UPSTART_JOB}.log‘ o qualcosa di simile. L’unica opzione per l’acquisizione dell’output altrimenti è la configurazione di ‘console‘ che vi lascia mandare l’output a /dev/console, ma questo non è utile..

Secondo: L’idioma comune ‘graceful restart’ (test e poi restart) difficilmente si implementa direttamente in Upstart.Io ho provato un modo,che è fare un test della config nel ‘pre-start’, e quando c’e’ successo, copiare il file in un file “buono” e partire con quello, ma questo non funziona bene per le cose come Nagios che possono avere molti file di configurazione:

# Imposta due variabili per una più facile manutenzione:
env CONFIG_FILE=/etc/nagios3/nagios.cfg
env NAGIOS=/usr/sbin/nagios3

pre-start script
  if $NAGIOS -v $CONFIG_FILE ; then
    # Copy to '.test_ok'
    cp $CONFIG_FILE ${CONFIG_FILE}.test_ok
  else
    echo "Config check failed, using old config."
  fi
end script

# Utilizza la config verificata 'test_ok'
exec $NAGIOS $CONFIG_FILE.test_ok

Il tipo di soluzione di cui sopra fa schifo. Il modo giusto per implementare il riavvio graceful ,con upstart, è quello di implementare il ‘test’ voi stessi e chiamare initctl restart nagios solo in caso di successo – vale a dire, tenerlo esterno ad upstart.

Terzo: D-Bus (Il backend dei messaggi per Upstart) ha una documentazione per l’utente scarsa. Il sistema sembra supportare il controllo dell’accesso, ma non riuscivo a trovare documentazione su questo argomento. Upstart non sembra parlare di come, ma si può vedere di controllo degli accessi in azione quando si tenta di fare ‘start’ ssh come non-root:

initctl: Rejected send message, 1 matched rules; type="method_call",
sender=":1.328" (uid=1000 pid=29686 comm="initctl)
interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)"
requested_reply=0 destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init"))

Quindi, c’è controllo degli accessi, ma non sono sicuro che qualcuno sappia come usarlo.

Quarto: Non c’è un evento “died” o “exited” per indicare che un processo è terminato inaspettatamente, così non si può avere dei task event-driven che ti avvisisino se un processo sta facendo up and down o per notificare con qualsiasi altro mezzo queste morti.

Quinto: Ancora una volta un problema di debug, non c’è modo di guardare gli eventi passando da upstart. strace non aiuta molto:

% sudo strace -s1500 -p 1 |& grep com.ubuntu.Upstart
# output edited for sanity, I ran 'sudo initctl start ssh'
read(10, "BEGIN ... binary mess ... /com/ubuntu/Upstart ... GetJobByName ...ssh\0", 2048) = 127
...

Infine, il sistema sembra come se fosse costruito per i desktop: la mancanza di un evento di ‘uscita’, confusione o mancanza di controllo degli accessi, lo stato di stopped probabilmente si perde dopo il riavvio, un avvio molto rapidof, poca/nessuna uscita sui fallimenti, ecc

CONCLUSIONI

In ogni caso, nonostante alcuni problemi, Upstart sembra una soluzione promettente per il problema del baby sittering dei proprio demoni. Se non ha altri vantaggi, il miglior vantaggio è che è diventato il default con Ubuntu 10.04 ed oltre, quindi se siete su una infrastruttura con Ubuntu, è utile impararlo.
Altre letture