Il supervisore non carica nuovi file di configurazione

Ho un problema con la distribuzione dell'app Django con Gunicorn e Supervisor. Mentre posso fare in modo che Gunicorn serva la mia app (impostando PYTHONPATH corretto ed eseguendo un comando appropriato, quello della configurazione di supervisord) non posso fare supervisore per eseguirla. Semplicemente non vedrà la mia app. Non so come assicurarmi se il file di configurazione è ok.

Ecco cosa dice il supervisore:

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

Lo sto eseguendo su Ubuntu 10.04 con la seguente configurazione:

File /home/myapp/live/deploy/supervisord_live.ini:

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

In /etc/supervisor/supervisord.conf, alla fine del file, c'è:

[include]
files = /etc/supervisor/conf.d/*.conf

ed ecco un link simbolico al mio file di configurazione:

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

mi sembra tutto perfetto, ma il supervisore continua a dirlo myapp_live: ERROR (no such process). Qualche soluzione per questo?

Ho avuto lo stesso problema, a

sudo service supervisord reload

fatto il trucco, anche se non so se questa è la risposta alla tua domanda.

La risposta corretta è che il supervisore richiede di rileggere e aggiornare quando si inserisce un nuovo file di configurazione. Il riavvio non è la risposta, poiché ciò influirà su altri servizi. Provare:

supervisorctl reread
supervisorctl update

Assicurarsi che i file di configurazione del supervisore finiscano con .conf

Mi ci è voluto un po 'per capirlo. Speriamo che aiuti la persona successiva.

Il ricaricamento del processo del supervisore principale può funzionare, ma avrà effetti collaterali indesiderati se il supervisore controlla più di un processo.

Il modo corretto per farlo è quello di supervisorctl rereadcausare che scansiona i file di configurazione per eventuali modifiche:

root@debian:~# supervisorctl reread
gunicorn: changed

Quindi, ricarica semplicemente l'app:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

Ho riscontrato questo problema utilizzando il pacchetto supervisore, versione 3.0a8-1.1 da Ubuntu Server 12.10. Ho finito per risolvere il problema leggendo la guida integrata:

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

In particolare si desidera utilizzare la sintassi:

sudo supervisorctl restart myapp_live:*

Come afferma la documentazione su http://supervisord.org/configuration.html#programx-section - "Una sezione [programma: x] rappresenta in realtà un" gruppo di processi omogeneo "per il supervisore (a partire da 3.0)." Quindi forse il problema è emerso per la prima volta nella versione 3.0.

PS: sono nuovo supervisore; Sto usando https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor come esempio di come dovrebbe essere una configurazione minima.

Ho avuto un problema simile ( myapp_live: ERROR (no such process)) ed era perché la mia definizione del processo era

[program: myapp_live]

quando avrebbe dovuto essere

[program:myapp_live]

Sebbene questo non affronti la domanda che mi è stata posta, sono stato guidato qui dalla Ricerca che sta cercando una soluzione al mio problema, quindi spero che anche altre persone lo trovino qui.

Ho trovato questa soluzione la più conveniente:

EDIT: prima di fare questo controlla il tuo percorso supervisore usando which supervisorctlper assicurarti di aggiungere il percorso giusto ai sudoers.

Aggiungi questa riga al file sudoers usando visudo(dove: myappuser- l'utente che deve riavviare la tua app, myapp- nome dell'app):

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

E poi semplicemente:

sudo supervisorctl restart myapp

Non sei legato agli script di avvio della distribuzione e dai privilegi piuttosto ristretti all'utente che riavvia l'app Gunicorn. Inoltre, non devi preoccuparti del pid. Il comando non chiederà la password, quindi è adatto per gli script bash / fabric a distribuzione automatica. D'altra parte, devi essere consapevole del fatto che se supervisorctl è vulnerabile ad alcuni bug che causano l'esecuzione di codice, un utente malintenzionato potrebbe usare questo privilegio sudo per eseguire il codice come root (ma per quanto ne so non è stato scoperto alcun bug di questo tipo per supervisione e è una grande cosa trovare tale vulnerabilità).

Leggendo il codice di supervisorctl.py qui: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Potete vedere che l'aggiornamento di supervisorctl (funzione do_update) chiama reloadConfig () esattamente come la rilettura di supervisorctl (funzione do_reread).

Quindi penso che chiamare la rilettura non sia necessario se si chiama update dopo.

Dall'output di git blame è stato così almeno dal luglio 2009.

Ecco una lista di controllo:

1. Il nuovo file di configurazione deve essere nominato secondo il modello di inclusione configurato in /etc/supervisord.conf:

   [include]
   files=supervisord.d/*.ini
   

   Come vediamo nel mio caso, spam.ini sarebbe incluso, ma spam.conf no.

2. Se hai creato il nuovo file copiandone uno vecchio, assicurati di cambiare effettivamente la [program:]linea. Perché se sei stupido come avere due file per lo stesso programma, supervisorctl rereadti lascerà con questo messaggio di errore senza speranza come punizione:

   No config updates to processes
   

3. Se il tuo file viene rilevato, supervisorctl rereaddovresti dire qualcosa del tipo:

   spam: available
   

4. Quindi, supervisorctl update spamdovrebbe avviarlo e farlo apparire supervisorctl status.

Ho trovato gli script init.d inaffidabili su una varietà di versioni differenti di Ubuntu / Debian. Il modo per farlo è questo:

sudo supervisorctl reload

Fai attenzione con i collegamenti simbolici e includi i file su Supervisor. Consentirebbe a qualsiasi persona con privilegio w su /home/myapp/live/deploy/supervisord_live.ini di modificare il file ini e avviare qualsiasi codice dannoso. Questi file ini devono trovarsi nella directory conf del supervisore o in qualsiasi sottodir sotto.

Avevo installato Supervrod con yum install, che installava il supervisore della versione v2. *. Supervisor supporta le inclusioni esterne solo dalla versione 3. Per installare supervisore v3 è stato invece necessario utilizzare easy_install.