我想在supervisord进程更改状态时收到通知。 我认为我configuration正确，但它不工作：当我改变一个进程的状态（即开始/停止），我收到没有电子邮件，没有看到任何信号故障。 这是主pipeconfiguration： [eventlistener:crashmail] command=/usr/local/bin/crashmail -a -m [email protected] events=PROCESS_STATE 主pipe状态告诉我，crashmail正在运行： crashmail RUNNING pid 54227, uptime 0:11:50 other RUNNING pid 54229, uptime 0:11:49 someother RUNNING pid 54267, uptime 0:10:59 在crashmail的stdout日志中，我发现如下所示： READY RESULT 2 OKREADY RESULT 2 OKREADY READY RESULT 2 OKREADY READY READY 而stderr是空的。 我试图启动/停止其他进程没有任何结果。 在我看来，supervisord没有发送事件到crashmail …我怎么检查这个？
对于Supervisord中的程序configuration块，如果redirect_stderr为true，是否需要设置stderr_logfile？ stderror_logfile=/path/to/logfile/stderr.log stdout_logfile=/path/to/logfile/stdout.log redirect_stderr=true 由于redirect_stderr为true，这意味着stderr.log将为空，并且stderr和stdoutstream的组合将显示在sdtout.log中。 我的理解是正确的吗？
我有问题得到哨兵（ https://www.getsentry.com – 没有足够的代表链接）作为服务使用主pipe。 我可以在命令行运行Sentry并在浏览器中正确地查看它，但是当涉及到主pipe时，我完全处于黑暗之中。 我会尽力给我所有的细节 初始用户警告 绝不是服务器pipe理员，只是在VirtualBox里玩/学习。 从字面上看，只是从阅读Sentry文档中发现了主pipe，所以我可能会在这里犯一些明显的错误。 设置： Ubuntu服务器11.10（全新安装，VirtualBox） 与Sentry及其依赖关系的virtualenv。 监 说明如下 主pipe与香草ini文件 哨兵/主pipe指示 我的主pipeini（哨兵部分） [program:sentry-web] directory=/root/.virtualenvs/sentry/ command= start http /root/.virtualenvs/sentry/bin/sentry autostart=true autorestart=true redirect_stderr=true 好的，我们走吧： 当我运行supervisord -n我得到以下消息，而不是一个漂亮的网页界面来玩。 2012-04-12 23:48:09,024 CRIT Supervisor running as root (no user in config file) 2012-04-12 23:48:09,097 INFO RPC interface 'supervisor' initialized 2012-04-12 23:48:09,099 CRIT Server 'unix_http_server' running without […]
我在Ubuntu上使用了几个监督程序来监督。 是否可以configurationpipe理程序，使其在另一个特定程序成功启动之前不启动程序？ 也就是说，只有在Zookeeper启动后才能运行Kafka。
主pipe可以启动uwsgi，但停止uwsgi后，当我尝试再次启动它，我得到这个错误： 2014-03-16 08:38:34,249 DEBG 'app' stderr output: thunder lock: disabled (you can enable it with –thunder-lock) 2014-03-16 08:38:34,249 DEBG 'app' stderr output: probably another instance of uWSGI is running on the same address (127.0.0.1:8001). 2014-03-16 08:38:34,249 DEBG 'app' stderr output: bind(): Address already in use [core/socket.c line 759] 2014-03-16 08:38:34,250 DEBG fd 11 closed, stopped […]
我使用supervisord的[program：x]来保持我的后台队列运行。 numprocs的数量被设置为一个静态数字，但现在我正在寻找一个解决scheme，根据队列的工作量来dynamic调整进程数量。 是否有可能（以编程方式）更改supervisord的numprocs设置的数量，而不影响已经运行的工人？
我有需要任意时间closures的过程，在2秒和几分钟之间的任何地方。 这个过程优雅地退出（而不是被杀死）是重要的。 我使用supervisord和ubuntu服务器来运行它。 当服务器获得ACPI关机信号（来自VPS提供商的重启命令，这就是EC2的假设），supervisord（以及整个系统）是否会在关机序列中等待所有subprocess退出？
我使用supervisor 3守护一个python进程，这个进程是通过一个为python设置一些configuration的bash脚本启动的。 bash脚本在前台运行python程序，FWIW。 这个设置有以下问题：当supervisord试图杀死进程时，它只会杀死bash脚本，而不是python进程。 所以我最终泄漏了运行旧代码的python进程，随后出现各种问题。 我怎样才能解决这个问题？ 主pipe是否有一些configuration选项来告诉它杀死subprocess？ bash脚本是否会捕获TERM信号并将其明确传递给孩子会有帮助吗？ 这似乎是不必要的，因为当我从交互式shell运行它，子python进程被杀死就好了。 我看到主pipe让我select要杀的信号，现在默认为TERM 。 可能改变这种帮助？
我与这样的主pipe运行docker集装箱： Dockerfile CMD ["/run.sh"] run.sh #!/usr/bin/env bash exec supervisord -n 主pipe-serf.conf [group:job] programs=serf,producer [program:serf] command=/start-serf-agent.sh numprocs=1 autostart=true autorestart=unexpected stopasgroup=true killasgroup=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 start-serf-agent.sh #!/bin/bash exec serf agent –join=serf:7946 -tag role=producer 主pipe-servce.conf [program:producer] command=/start.sh numprocs=1 stopasgroup=true killasgroup=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 start.sh #!/bin/bash exec /producer –project=${NAME} 制片人停下来之后我得到了： producer_1 | 2016/02/29 21:59:50 [INFO] serf: EventMemberLeave: […]
我试图在主pipe中运行一个gunicorn_django进程，但它总是立即退出，出现这个错误： INFO exited: my_app (exit status 1; not expected) INFO received SIGCLD indicating a child quit INFO gave up: my_app entered FATAL state, too many start retries too quickly 我的服务器脚本如下所示： #!/bin/bash set -e LOGFILE=/var/log/gunicorn/my_app.log LOGDIR=$(dirname $LOGFILE) NUM_WORKERS=3 USER=my-www-user GROUP=my-www-user cd /home/my-www-user/my_app source /home/my-www-user/.virtualenvs/my_app/bin/activate test -d $LOGDIR || mkdir -p $LOGDIR gunicorn_django -w $NUM_WORKERS –debug \ […]