Come posso assicurarmi che un lavoro Upstart inizi prima di altri lavori Upstart?

Questa è una domanda generale di Upstart, ma lasciami usare un caso specifico:

Centrify è un gateway da NIS a ActiveDirectory. Deve essere caricato prima di qualsiasi servizio che dipenderà dal servizio di autenticazione fornito, ad esempio autofs, cron, nis, et al.

Ciò ha dimostrato di essere abbastanza impegnativo da raggiungere, anche quando si cerca di cambiare le dipendenze degli altri servizi (cosa che non penso che dovremmo fare comunque, non voglio toccare gli altri lavori Upstart, se possibile) .

Suggerimenti?

boot upstart init

— Mark Russell
fonte

Risposte:

La soluzione è quella di affrontare il problema dall'altra direzione: per soddisfare i criteri di avvio di Centrify, non è necessario far dipendere i servizi esistenti dal nuovo servizio Centrify, piuttosto fare dipendere il nuovo servizio Centrify dai servizi esistenti.

Ad esempio, un file di configurazione di Upstart /etc/init/centrify.confpotrebbe dire:

start on (avvio cron o avvio autofs o avvio nis)

Convertendolo in inglese, questo si tradurrebbe in:

avvia il servizio Centrify poco prima dell'avvio di cron, autofs o nis (a seconda di quale avvio si avvia per primo).

L'ordine in cui cron, autofs o nis si avvia è irrilevante: Upstart garantirà l'avvio di Centrify prima dell'inizio di qualsiasi servizio, garantendo così che Centrify sia in esecuzione prima dell'avvio di uno di tali servizi.

Nota anche che Upstart bloccherà l'avvio del primo servizio che vuole avviarsi fino a quando Centrify non ha iniziato a funzionare.

Molto elegante e semplice quando ti abitui a pensare in questo modo.

— James Hunt
fonte

questo mi sembra totalmente arretrato. perché lo script conf per un servizio dovrebbe essere modificato quando altre cose dipendono da esso ?

— ben w

@benw In modo da non dover modificare le impostazioni esistenti dei servizi che non possiedi.

— Paccc,

@Paccc quando scrivo un nuovo script che dipende da nginx, devo modificare lo script conf per nginx ... che non possiedo.

— ben w

@benw Perché non puoi utilizzarlo start on (started nginx)nel tuo nuovo script?

— Paccc,

@Paccc non proprio. start on (started nginx)significa "avvia il mio servizio dopo nginx". Che non è lo stesso di "avvia nginx prima del mio servizio perché ne ha bisogno".

— sickill

La risposta di James funziona per una dipendenza da 1 a 1. Da 1 a molti, ovvero per assicurarsi che il servizio A inizi prima dei servizi B, C e D, è necessario adottare un altro approccio. È possibile consultare gli script della portmap corrente come riferimento, ma qui è l'approccio generale: creare uno script wait.

Scenario: si desidera che il servizio A venga eseguito sempre prima di service-b, service-c e service-d.

Soluzione: creare uno script di attesa per il servizio A. Chiamarlo "/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

Ciò significa in parole povere: quando il servizio b, c o d segnala che vogliono iniziare, devono attendere l'avvio fino a quando il servizio-a è in esecuzione. Il lavoro service-a-wait è progettato per essere eseguito fino all'avvio di service-a. Una volta terminato il servizio di attesa, ora i servizi b, c e d sono liberi di continuare ed eseguire.

Questo assicurerà che il servizio-a sia attivo e funzionante prima che una qualsiasi delle sue dipendenze inverse tenti di avviarsi.

Nota: la riga "istanza $ JOB" è importante in questo scenario "start on ... or .. or ..". Altrimenti bloccherai davvero solo per uno qualsiasi degli incendi B, C o D per primi.

(l'istanza merita una spiegazione migliore onestamente. per ora, basta farlo.;)

— Mark Russell
fonte

Non capisco ... cosa impedisce a una condizione di competizione tra l'avvio del servizio A e il servizio B che continua ad iniziare? Non vedo come upstart saprà che lo script ha completato "start service-a" ... (la colpa è forse della scadente documentazione di Upstart ...)

— Chris Pacejo,

@Mark Russell: Non dovrebbe normal exit 2essere normal exit 0 2invece quella linea ? La prima riga nella scriptsezione può chiaramente exit 0.

— froage