2012-09-26 19 views
8

Abbiamo un'applicazione daemon C++ personalizzata che si biforca una volta. Così abbiamo fatto questo nel nostro script Upstart su Ubuntu 12.04 e funziona perfettamente:Come impostare la variabile di ambiente in pre-avvio nello script Upstart?

expect fork 
exec /path/to/the/app 

Comunque ora abbiamo bisogno di passare a un argomento per la nostra applicazione che contiene il numero di CPU sulla macchina su cui piste:

cat /proc/cpuinfo | grep processor | wc -l 

il nostro primo tentativo è stato questo:

expect fork 
exec /path/to/the/app -t `cat /proc/cpuinfo | grep processor | wc -l` 

Mentre che inizia la nostra applicazione con il valore corretto -t, Upstart tracce il valore pid sbagliato, sto assumendo perché quelli cat , grep & wc comanda tutti i processi di avvio in exec prima della nostra app.

Ho anche provato questo, e anche non funziona, credo perché l'impostazione di un env var esegue un processo? Upstart segue ancora il pid sbagliato:

expect fork 
script 
    NUM_CORES=32 
    /path/to/the/app -t $NUM_CORES 
end script 

Ho anche provato a fare questo in uno strofa env ma a quanto pare quelli non eseguire i comandi:

env num_cores=`cat /proc/cpuinfo | grep processor | wc -l` 

anche provato a fare questo in pre-start, ma ENV le variabili di impostare lì non hanno alcun valore nella stanza exec:

pre-start 
    NUM_CORES=32 
end script 

Qualsiasi idea di come ottenere questo NUM_CORES impostato correttamente, e ancora ottenere Upstart per monitorare il corretto PID per la nostra applicazione che si biforca una volta?

risposta

16

È imbarazzante. Il metodo consigliato è scrivere un file env nella stanza di pre-avvio e quindi inviarlo nella stanza dello script. È ridicolo, lo so.

expect fork 

pre-start script 
    exec >"/tmp/$UPSTART_JOB" 
    echo "NUM_CORES=$(cat /proc/cpuinfo | grep processor | wc -l)" 
end script 

script 
    . "/tmp/$UPSTART_JOB" 
    /path/to/app -t "$NUM_CORES" 
end script 

post-start script 
    rm -f "/tmp/$UPSTART_JOB" 
end script 

utilizzare la linea exec nel pre-start, perché di solito ho più variabili env e io non voglio ripetere il codice di reindirizzamento.

Questo funziona solo perché il '. 'command è un dash incorporato e quindi non viene generato alcun processo.

+0

super disponibile! Una cosa: penso che tu abbia ancora bisogno di usare "exec/path/to/app" all'interno del blocco di script se questo è quello che ti serviva prima per il tracciamento dei pid. Una volta aggiunto "exec", questo ha funzionato magnificamente per me. –

+0

@ CodyA.Ray dipende completamente dal comportamento di biforcazione del servizio avviato. Nel nostro caso, 'expect daemon' potrebbe essere appropriato. – mpm

0

vorrei aggiungere

export NUM_CORES 

dopo l'assegnazione è un valore in "script". Ricordo che un/bin/sh collegato a una shell non Bash può eseguire script, quindi evito i costrutti di Bash.

Ri: utilizzando la stanza "env", passa letteralmente i valori e non li elabora utilizzando le convenzioni della shell.

2

Secondo config parvenu di zram-config:

script 
    NUM_CORES=$(grep -c ^processor /proc/cpuinfo | sed 's/^0$/1/') 
    /path/to/the/app -t $NUM_CORES 
end script 
+0

Il problema è che '$()' forchetta un processo figlio (e poi la pipe causa un altro fork), che può confondere il fork tracking.Se biforchi più di due volte prima del tuo demone effettivo, il vecchio upstart non può seguire il processo del demone e quindi respawn non funzionerà correttamente. Questo funziona per zram-config perché funziona solo una volta e non ha bisogno di respawn, ma non è universale. :) Ecco perché è necessaria la risposta di @ mpm. – dannysauer

Problemi correlati