Supervisor error no such process

Supervisor not loading new configuration files I have a problem deploying Django app using Gunicorn and Supervisor. While I can make Gunicorn serving my app (by setting proper PYTHONPATH and running apropriate command, the one from supervisord config) I can’t make supervisor to run it. It just won’t see my app. I don’t know […]

Содержание

  1. Supervisor not loading new configuration files
  2. 12 Answers 12
  3. Supervisorctl ERROR (нет такого процесса)
  4. ОТВЕТЫ
  5. Ответ 1
  6. Ответ 2
  7. Ответ 3
  8. Ответ 4
  9. Ответ 5
  10. Supervisor не загружает новые файлы конфигурации
  11. Twemsentinel : supervisor restart error : nutcracker: ERROR (no such process) #2
  12. Comments

Supervisor not loading new configuration files

I have a problem deploying Django app using Gunicorn and Supervisor. While I can make Gunicorn serving my app (by setting proper PYTHONPATH and running apropriate command, the one from supervisord config) I can’t make supervisor to run it. It just won’t see my app. I don’t know how to make sure if the config file is ok.

Here’s what supervisorctl says:

I’m running it on Ubuntu 10.04 with following config:

In /etc/supervisor/supervisord.conf, at the end of the file, there is:

and here’s a symlink to my config file:

everything looks fine for me but supervisorctl just keep saying myapp_live: ERROR (no such process) . Any solution for this?

12 Answers 12

I had the same issue, a

did the trick, though I don’t know if that is the answer to your question.

The correct answer is that supervisor requires you to re-read and update when you place a new configuration file. Restarting is not the answer, as that will affect other services. Try:

Make sure your supervisor conf files end in .conf

Took me a while to figure that one out. Hopefully it helps the next person.

Reloading the master supervisor process may work, but it will have unintended side effects if you have more than one process being monitored by supervisor.

The correct way to do it is to issue supervisorctl reread which causes it to scan configuration files for any changes:

Then, simply reload that app:

I had a similar problem ( myapp_live: ERROR (no such process) ) and it was because my process definition was

when it should have been

While this doesn’t address the question that was asked, I was lead here by the Search that Be looking for a solution to my problem, so hopefully other people find it here, too.

I encountered this problem using the supervisor package, version 3.0a8-1.1 from Ubuntu Server 12.10. I ended up solving the problem by reading the built-in help:

In particular you want to use the syntax:

As the documentation states at http://supervisord.org/configuration.html#programx-section — «A [program:x] section actually represents a “homogeneous process group” to supervisor (as of 3.0).» So maybe the problem first surfaced in version 3.0.

Here is a checklist:

The new config file should be named according to the include pattern configured in /etc/supervisord.conf:

As we see in my case, spam.ini would be included, but spam.conf would not.

If you created the new file by copying an old one, make sure to actually change the [program:] line. Otherwise, supervisorctl reread will not tell you so:

If your file is detected, supervisorctl reread should say something like:

Then, supervisorctl update spam should both start it and make it appear in supervisorctl status .

I’ve found the init.d scripts to be unreliable on a variety of different Ubuntu/Debian versions. The way to do it is this:

I found this solution to be most convenient:

EDIT: before doing this check your supervisorctl path using which supervisorctl to make sure you are adding right path to sudoers.

Add this line to sudoers file using visudo (where: myappuser — the user that needs to restart your app, myapp — app name):

And then simply:

You are not tied to distribution’s startup scripts and you give quite narrow privileges to user restarting your gunicorn app. Also, you don’t need to care about pid. The command will not ask for password so it’s suitable for auto-deployment bash/fabric scripts. On the other hand — you have to be aware, that if supervisorctl is vulnerable to some bug causing code execution a malicious user could use this sudo privilege to run code as root (but as far as I know no such bug was discovered for supervisord and it’s a big thing to find such vulnerability).

Источник

Supervisorctl ERROR (нет такого процесса)

Я видел этот вопрос раньше, но ни одно из решений не сработало для меня.

У меня возникают проблемы с использованием диспетчера на моем rpi b+. Каждый раз, когда я пытаюсь запустить мой процесс, я получаю сообщение об ошибке:

$sudo supervisorctl start server

server: ERROR (нет такого процесса)

У меня есть файл конфигурации, установленный в /etc/supervisord.conf

Я попытался выполнить команды перечитания, обновления, перезагрузки, но они не сработали. Любые идеи?

ОТВЕТЫ

Ответ 1

Вам следует попытаться перезагрузить supervisord :

Во многих случаях эта ошибка разрешается перезагрузкой.

Ответ 2

сначала запустите службу SupervisorD, используя следующую команду:

Вы можете проверить, используя: ps -ef | grep python

После запуска супервизора, попробуйте запустить свою программу, используя следующую команду:

Ответ 3

На моей Fedora22 я изменил строки ниже в /etc/supervisord.conf :

а затем перезагрузите

Ответ 4

В некоторых версиях супервизора раздел [include] не работает, вам нужно добавить программы в основной файл конфигурации супервизора в /etc/supervisord.conf

Ответ 5

В случае многостадийного процесс экземпляров конфигурации полного имени процесса может выглядеть server:server_0 (зависит от вашего process_name шаблона). Пытаться:

В противном случае вы получите ту же ошибку (без такого процесса).

Источник

Supervisor не загружает новые файлы конфигурации

У меня проблема с развертыванием приложения Django с использованием Gunicorn и Supervisor. Хотя я могу сделать так, чтобы Gunicorn обслуживал мое приложение (установив правильный PYTHONPATH и выполнив соответствующую команду, например, из конфигурации supervisord), я не могу заставить supervisor запускать его. Он просто не увидит мое приложение. Я не знаю, как убедиться, что файл конфигурации в порядке.

Вот что говорит supervisorctl:

Я запускаю его на Ubuntu 10.04 со следующим конфигом:

В /etc/supervisor/supervisord.conf в конце файла находится:

и вот символическая ссылка на мой конфигурационный файл:

все выглядит хорошо для меня, но supervisorctl просто продолжаю говорить myapp_live: ERROR (no such process) . Любое решение для этого?

У меня была такая же проблема,

сделал свое дело, хотя я не знаю, если это ответ на ваш вопрос.

Правильный ответ заключается в том, что супервизор требует, чтобы вы перечитывали и обновляли при размещении нового файла конфигурации. Перезапуск не является ответом, так как это повлияет на другие службы. Пытаться:

Убедитесь, что ваши файлы conf supervisor заканчиваются на .conf

Мне понадобилось время, чтобы понять это. Надеюсь, это поможет следующему человеку.

Перезагрузка главного процесса супервизора может сработать, но у него будут непредвиденные побочные эффекты, если супервизор контролирует более одного процесса.

Правильный способ сделать это — выполнить команду, supervisorctl reread которая заставляет его сканировать файлы конфигурации на наличие изменений:

Затем просто перезагрузите это приложение:

Я столкнулся с этой проблемой, используя пакет supervisor, версия 3.0a8-1.1 из Ubuntu Server 12.10. Я решил проблему, прочитав встроенную справку:

В частности, вы хотите использовать синтаксис:

Как указано в документации по адресу: http://supervisord.org/configuration.html#programx-section — «Раздел [program: x] фактически представляет« однородную группу процессов »для супервизора (начиная с версии 3.0)». Так что, возможно, проблема впервые появилась в версии 3.0.

У меня была похожая проблема ( myapp_live: ERROR (no such process) ), и это потому, что мое определение процесса было

когда это должно было быть

Хотя это не относится к заданному вопросу, я был здесь в поиске, который ищет решение моей проблемы, так что, надеюсь, другие тоже найдут его здесь.

Я нашел это решение наиболее удобным:

РЕДАКТИРОВАТЬ: перед этим проверьте ваш путь supervisorctl с помощью, which supervisorctl чтобы убедиться, что вы добавляете правильный путь к sudoers.

Добавьте эту строку в файл sudoers, используя visudo (где: myappuser — пользователь, которому нужно перезапустить ваше приложение, myapp — имя приложения):

Вы не привязаны к сценариям запуска дистрибутива и даете пользователю довольно узкие права на перезапуск вашего приложения gunicorn. Кроме того, вам не нужно заботиться о pid. Команда не запрашивает пароль, поэтому она подходит для сценариев bash / fabric с автоматическим развертыванием. С другой стороны — вы должны знать, что если supervisorctl уязвим к некоторой ошибке, вызывающей выполнение кода, злоумышленник может использовать эту привилегию sudo для запуска кода от имени пользователя root (но, насколько я знаю, такой ошибки не было обнаружено для supervisord и найти такую ​​уязвимость очень важно).

Источник

Twemsentinel : supervisor restart error : nutcracker: ERROR (no such process) #2

I have just configure the twemsentinel but facing below error while restart the sentinel.

restart
nutcracker: ERROR (no such process)
nutcracker: ERROR (no such process)
restart error

sentinel_ip: «10.247.74.38»
sentinel_port: «26380»
twemproxy_config_file: «nutcracker.yml»
nutcracker_restart_command: «supervisorctl restart nutcracker»
log_file: «twemsentinel.log»

Please help to resolve the issue.

The text was updated successfully, but these errors were encountered:

Hi
You should install nutcracker ( https://github.com/twitter/twemproxy ) and set nutcracker_restart_command in config.yml
I used supervisord for restart nutcracker (http://supervisord.org/)

I have already installed the nutcracker and run through with below command.

cache 15407 1 0 16:20 ? 00:00:05 /home/cache/.gem/ruby/gems/nutcracker-0.4.1.20/ext/nutcracker/src/nutcracker -c ../conf/nutcracker.yml -p /var/run/nutcracker/nutcracker.pid

I am using supervisorctl to restart the nutcracker service but it gives below error

nutcracker: ERROR (no such process)
nutcracker: ERROR (no such process)

But it unable to find the process id of nutcracker to restart the process.

Also please share the command how to restart the nutcracker through supervisord.

The problem is not about twemsentinel
Your supervisorctl cant find nutcracker process. Did you try «supervisorctl reload» and «supervisorctl update»

Try in terminal «supervisorctl restart all» or «supervisorctl restart nuctracker(or you program name)»

how to run it through supervisord. We are getting error while running below command.

supervisord restart nutcracker

Error :- positional arguements are not supported.

can you paste supervisord program conf file

; Sample supervisor config file.
;
; For more information on the config file, please see:
; http://supervisord.org/configuration.html
;
; Note: shell expansion («

» or «$HOME») is not supported. Environment
; variables can be expanded using this syntax: «%(ENV_HOME)s».

[unix_http_server]
file=/tmp/supervisor.sock ; (the path to the socket file)
chmod=0777 ; socket file mode (default 0700)
chown=cache:cache ; socket file uid:gid owner
;username=user ; (default is no username (open server))
;password=123 ; (default is no password (open server))

;[inet_http_server] ; inet (TCP) server disabled by default
;port=127.0.0.1:9001 ; (ip_address:port specifier, *:port for all iface)
;username=user ; (default is no username (open server))
;password=123 ; (default is no password (open server))

[supervisord]
logfile=/home/cache/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=/home/cache/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)
;umask=022 ; (process file creation umask;default 022)
user=cache ; (default is current user, required if root)
;identifier=supervisor ; (supervisord identifier, default is ‘supervisor’)
;directory=/tmp ; (default is not to cd during start)
;nocleanup=true ; (don’t clean up tempfiles at start;default false)
;childlogdir=/tmp ; (‘AUTO’ child log dir, default $TEMP)
;environment=KEY=»value» ; (key value pairs to add to environment)
;strip_ansi=false ; (strip ansi escape codes in logs; def. false)

; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; use a unix:// URL for a unix socket
user=cache
;serverurl=http://127.0.0.1:9001 ; use an http:// url to specify an inet socket
;username=chris ; should be same as http_username if set
;password=123 ; should be same as http_password if set
;prompt=mysupervisor ; cmd line prompt (default «supervisor»)
;history_file=

/.sc_history ; use readline history if available

; The below sample program section shows all possible program subsection values,
; create one or more ‘real’ program: sections to be able to control them under
; supervisor.

;[program:theprogramname]
;command=/bin/cat ; the program (relative uses PATH, can take args)
;process_name=%(program_name)s ; process_name expr (default %(program_name)s)
;numprocs=1 ; number of processes copies to start (def 1)
;directory=/tmp ; directory to cwd to before exec (def no cwd)
;umask=022 ; umask for process (default None)
;priority=999 ; the relative start priority (default 999)
;autostart=true ; start at supervisord start (default: true)
;autorestart=unexpected ; whether/when to restart (default: unexpected)
;startsecs=1 ; number of secs prog must stay running (def. 1)
;startretries=3 ; max # of serial start failures (default 3)
;exitcodes=0,2 ; ‘expected’ exit codes for process (default 0,2)
;stopsignal=QUIT ; signal used to kill process (default TERM)
;stopwaitsecs=10 ; max num secs to wait b4 SIGKILL (default 10)
;stopasgroup=false ; send stop signal to the UNIX process group (default false)
;killasgroup=false ; SIGKILL the UNIX process group (def false)
user=cache ; setuid to this UNIX account to run the program
;redirect_stderr=true ; redirect proc stderr to stdout (default false)
;stdout_logfile=/a/path ; stdout log path, NONE for none; default AUTO
;stdout_logfile_maxbytes=1MB ; max # logfile bytes b4 rotation (default 50MB)
;stdout_logfile_backups=10 ; # of stdout logfile backups (default 10)
;stdout_capture_maxbytes=1MB ; number of bytes in ‘capturemode’ (default 0)
;stdout_events_enabled=false ; emit events on stdout writes (default false)
;stderr_logfile=/a/path ; stderr log path, NONE for none; default AUTO
;stderr_logfile_maxbytes=1MB ; max # logfile bytes b4 rotation (default 50MB)
;stderr_logfile_backups=10 ; # of stderr logfile backups (default 10)
;stderr_capture_maxbytes=1MB ; number of bytes in ‘capturemode’ (default 0)
;stderr_events_enabled=false ; emit events on stderr writes (default false)
;environment=A=»1″,B=»2″ ; process environment additions (def no adds)
;serverurl=AUTO ; override serverurl computation (childutils)

; The below sample eventlistener section shows all possible
; eventlistener subsection values, create one or more ‘real’
; eventlistener: sections to be able to handle event notifications
; sent by supervisor.

;[eventlistener:theeventlistenername]
;command=/bin/eventlistener ; the program (relative uses PATH, can take args)
;process_name=%(program_name)s ; process_name expr (default %(program_name)s)
;numprocs=1 ; number of processes copies to start (def 1)
;events=EVENT ; event notif. types to subscribe to (req’d)
;buffer_size=10 ; event buffer queue size (default 10)
;directory=/tmp ; directory to cwd to before exec (def no cwd)
;umask=022 ; umask for process (default None)
;priority=-1 ; the relative start priority (default -1)
;autostart=true ; start at supervisord start (default: true)
;autorestart=unexpected ; whether/when to restart (default: unexpected)
;startsecs=1 ; number of secs prog must stay running (def. 1)
;startretries=3 ; max # of serial start failures (default 3)
;exitcodes=0,2 ; ‘expected’ exit codes for process (default 0,2)
;stopsignal=QUIT ; signal used to kill process (default TERM)
;stopwaitsecs=10 ; max num secs to wait b4 SIGKILL (default 10)
;stopasgroup=false ; send stop signal to the UNIX process group (default false)
;killasgroup=false ; SIGKILL the UNIX process group (def false)
user=cache ; setuid to this UNIX account to run the program
;redirect_stderr=true ; redirect proc stderr to stdout (default false)
;stdout_logfile=/a/path ; stdout log path, NONE for none; default AUTO
;stdout_logfile_maxbytes=1MB ; max # logfile bytes b4 rotation (default 50MB)
;stdout_logfile_backups=10 ; # of stdout logfile backups (default 10)
;stdout_events_enabled=false ; emit events on stdout writes (default false)
;stderr_logfile=/a/path ; stderr log path, NONE for none; default AUTO
;stderr_logfile_maxbytes=1MB ; max # logfile bytes b4 rotation (default 50MB)
;stderr_logfile_backups ; # of stderr logfile backups (default 10)
;stderr_events_enabled=false ; emit events on stderr writes (default false)
;environment=A=»1″,B=»2″ ; process environment additions
;serverurl=AUTO ; override serverurl computation (childutils)

; The below sample group section shows all possible group values,
; create one or more ‘real’ group: sections to create «heterogeneous»
; process groups.

;[group:thegroupname]
;programs=progname1,progname2 ; each refers to ‘x’ in [program:x] definitions
;priority=999 ; the relative start priority (default 999)

; The [include] section can just contain the «files» setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files cannot
; include files themselves.

;[include]
;files = relative/directory/*.ini

Источник

Я видел этот вопрос раньше, но ни одно из решений не сработало для меня.

У меня возникают проблемы с использованием диспетчера на моем rpi b+. Каждый раз, когда я пытаюсь запустить мой процесс, я получаю сообщение об ошибке:

pi @raspberrypi ~ $sudo supervisorctl start server

server: ERROR (нет такого процесса)

У меня есть файл конфигурации, установленный в /etc/supervisord.conf

[program:server]
directory=/home/pi/ledticker
command=/usr/bin/python NetworkServer.py
autostart=false
autorestart=true
stopsignal=QUIT

[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; use a unix:// URL for a unix socket

[unix_http_server]
file=/tmp/supervisor.sock ; (the path to the socket file)

Я попытался выполнить команды перечитания, обновления, перезагрузки, но они не сработали. Любые идеи?

4b9b3361

Ответ 1

Вам следует попытаться перезагрузить supervisord:

# supervisorctl reload
[y/N] ? y

Во многих случаях эта ошибка разрешается перезагрузкой.

Ответ 2

Раньше я сталкивался с такой же проблемой. Это было решением следующих решений.
Сначала отредактируйте файл supervisord.conf и добавьте строки ниже:

[unix_http_server]

file=/tmp/supervisor.sock

chmod=0777
  • сначала запустите службу SupervisorD, используя следующую команду:

    $ sudo /usr/bin/supervisord -c /etc/supervisord.conf
    
  • Вы можете проверить, используя: ps -ef | grep python

  • После запуска супервизора, попробуйте запустить свою программу, используя следующую команду:

    $ sudo /usr/bin/supervisorctl -c /etc/supervisord.conf start all
    

Ответ 3

На моей Fedora22 я изменил строки ниже в /etc/supervisord.conf:

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

к

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

а затем перезагрузите

Ответ 4

В некоторых версиях супервизора раздел [include] не работает, вам нужно добавить программы в основной файл конфигурации супервизора в /etc/supervisord.conf

Ответ 5

В случае многостадийного процесс экземпляров конфигурации полного имени процесса может выглядеть server:server_0 (зависит от вашего process_name шаблона). Пытаться:

sudo supervisorctl restart server:*

В противном случае вы получите ту же ошибку (без такого процесса).


У меня проблема с развертыванием приложения Django с использованием Gunicorn и Supervisor. Хотя я могу сделать так, чтобы Gunicorn обслуживал мое приложение (установив правильный PYTHONPATH и выполнив соответствующую команду, например, из конфигурации supervisord), я не могу заставить supervisor запускать его. Он просто не увидит мое приложение. Я не знаю, как убедиться, что файл конфигурации в порядке.

Вот что говорит supervisorctl:

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

Я запускаю его на Ubuntu 10.04 со следующим конфигом:

Файл /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

В /etc/supervisor/supervisord.conf в конце файла находится:

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

и вот символическая ссылка на мой конфигурационный файл:

# 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

все выглядит хорошо для меня, но supervisorctl просто продолжаю говорить myapp_live: ERROR (no such process). Любое решение для этого?


Ответы:


У меня была такая же проблема,

sudo service supervisord reload

сделал свое дело, хотя я не знаю, если это ответ на ваш вопрос.







Правильный ответ заключается в том, что супервизор требует, чтобы вы перечитывали и обновляли при размещении нового файла конфигурации. Перезапуск не является ответом, так как это повлияет на другие службы. Пытаться:

supervisorctl reread
supervisorctl update






Убедитесь, что ваши файлы conf supervisor заканчиваются на .conf

Мне понадобилось время, чтобы понять это. Надеюсь, это поможет следующему человеку.




Перезагрузка главного процесса супервизора может сработать, но у него будут непредвиденные побочные эффекты, если супервизор контролирует более одного процесса.

Правильный способ сделать это — выполнить команду, supervisorctl rereadкоторая заставляет его сканировать файлы конфигурации на наличие изменений:

root@debian:~# supervisorctl reread
gunicorn: changed

Затем просто перезагрузите это приложение:

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




Я столкнулся с этой проблемой, используя пакет supervisor, версия 3.0a8-1.1 из Ubuntu Server 12.10. Я решил проблему, прочитав встроенную справку:

$ 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

В частности, вы хотите использовать синтаксис:

sudo supervisorctl restart myapp_live:*

Как указано в документации по адресу: http://supervisord.org/configuration.html#programx-section — «Раздел [program: x] фактически представляет« однородную группу процессов »для супервизора (начиная с версии 3.0)». Так что, возможно, проблема впервые появилась в версии 3.0.

PS: я новичок в супервизоре; Я использую https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor в качестве примера того, как должна выглядеть минимальная конфигурация.


У меня была похожая проблема ( myapp_live: ERROR (no such process)), и это потому, что мое определение процесса было

[program: myapp_live]

когда это должно было быть

[program:myapp_live]

Хотя это не относится к заданному вопросу, я был здесь в поиске, который ищет решение моей проблемы, так что, надеюсь, другие тоже найдут его здесь.



Я нашел это решение наиболее удобным:

РЕДАКТИРОВАТЬ: перед этим проверьте ваш путь supervisorctl с помощью, which supervisorctlчтобы убедиться, что вы добавляете правильный путь к sudoers.

Добавьте эту строку в файл sudoers, используя visudo(где: myappuser— пользователь, которому нужно перезапустить ваше приложение, myapp— имя приложения):

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

А потом просто:

sudo supervisorctl restart myapp

Вы не привязаны к сценариям запуска дистрибутива и даете пользователю довольно узкие права на перезапуск вашего приложения gunicorn. Кроме того, вам не нужно заботиться о pid. Команда не запрашивает пароль, поэтому она подходит для сценариев bash / fabric с автоматическим развертыванием. С другой стороны — вы должны знать, что если supervisorctl уязвим к некоторой ошибке, вызывающей выполнение кода, злоумышленник может использовать эту привилегию sudo для запуска кода от имени пользователя root (но, насколько я знаю, такой ошибки не было обнаружено для supervisord и найти такую ​​уязвимость очень важно).


Читая код supervisorctl.py здесь:
https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Вы можете видеть, что обновление supervisorctl (функция do_update) вызывает reloadConfig () точно так же, как и повторное чтение supervisorctl (функция do_reread).

Поэтому я думаю, что повторное чтение вызова не нужно, если вы вызываете обновление после него.

По результатам мерзавца, это было так, по крайней мере, с июля 2009 года.


Вот контрольный список:

  1. Новый файл конфигурации должен быть назван в соответствии с шаблоном включения, настроенным в /etc/supervisord.conf:

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

    Как мы видим в моем случае, spam.ini будет включен, а spam.conf — нет.

  2. Если вы создали новый файл, скопировав старый, обязательно измените [program:]строку. Потому что, если вы настолько глупы, как наличие двух файлов для одной и той же программы, supervisorctl rereadвы получите это безнадежное сообщение об ошибке в качестве наказания:

    No config updates to processes
    
  3. Если ваш файл обнаружен, supervisorctl rereadследует сказать что-то вроде:

    spam: available
    
  4. Затем supervisorctl update spamследует запустить его и сделать так, чтобы он появился в supervisorctl status.


Я обнаружил, что сценарии init.d ненадежны в различных версиях Ubuntu / Debian. Способ сделать это так:

sudo supervisorctl reload



Будьте осторожны с символическими ссылками и включайте файлы в Supervisor. Это позволило бы любому человеку с привилегией w на /home/myapp/live/deploy/supervisord_live.ini изменить INI-файл и запустить любой вредоносный код. Эти INI-файлы должны находиться в каталоге conf вашего супервизора или в любом его подкаталоге.


Я установил supervisrod с помощью yum install, который установил супервизор версии v2. *. Supervisor поддерживает внешние включения только из версии 3. Пришлось использовать easy_install вместо этого, чтобы установить supervisor v3.


Понравилась статья? Поделить с друзьями:
  • Supersocket info spnregister error 1355
  • Supermicro ошибка ba
  • Superior drummer 3 midi error как исправить
  • Superior drummer 3 grooves midi error
  • Superfetch не выполняется windows 7 как исправить ошибку