Hi there. Thanks a lot for supervisor, I am using it on quite a few servers and it is performing greatly.

I would like to suggest a feature that would be very advantageous (well, at least for me). There are some processes that support receiving a certain signal, such as HUP, causing them to perform a graceful restart.

Examples for such processes include the HTTP web server Cherokee (http://www.cherokee-project.com) and servers initiated via Perl's Server::Starter (http://search.cpan.org/dist/Server-Starter), which acts as a superdaemon.

If I could set on supervisord.conf that a certain process is restarted with a HUP signal, just like I can set the signal for stopping a process, then I could just do "restart process_name" and get the correct behaviour. That would be awesome.

Thanks a lot, Ido Perlmuter.

I don't seem to be able to get supervisor to run! Here are the details:

vagrant@homestead:/etc/supervisor$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04 LTS Release: 14.04 Codename: trusty vagrant@homestead:/etc/su

vagrant@homestead:/etc/supervisor$ sudo apt-get install supervisor Reading package lists... Done Building dependency tree
Reading state information... Done supervisor is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 70 not upgraded.

vagrant@homestead:/etc/supervisor$ sudo service supervisor restart Restarting supervisor: supervisord.

vagrant@homestead:/etc/supervisor$ sudo supervisord /usr/lib/python2.7/dist-packages/supervisor/options.py:295: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security. 'Supervisord is running as root and it is searching '

vagrant@homestead:/etc/supervisor$ sudo supervisorctl unix:///var/run/supervisor.sock no such file supervisor> help

default commands (type help ):

add clear fg open quit remove restart start stop update avail exit maintail pid reload reread shutdown status tail version

supervisor> reread error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 224

supervisor> update error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 224

Here are some more details:

vagrant@homestead:/etc/supervisor$ sudo apt-cache show supervisor Package: supervisor Priority: extra Section: universe/admin Installed-Size: 1485 Maintainer: Ubuntu Developers [email protected] Original-Maintainer: Qijiang Fan [email protected] Architecture: all Version: 3.0b2-1 Depends: python, python-meld3, python-pkg-resources (>= 0.6c7) Filename: pool/universe/s/supervisor/supervisor_3.0b2-1_all.deb Size: 313972 MD5sum: 1e5ee03933451a0f4fc9ff391404f292 SHA1: d9dc47366e99e77b6577a9a82abd538c4982c58e SHA256: f83f89a439cc8de5f2a545edbf20506695e4b477c579a5824c063fbaf94127c1 Description-en: A system for controlling process state Supervisor is a system for controlling and maintaining process state, similar to what init does, but not intended as an init replacement. . It will manage individual processes or groups of processes that need to be started and stopped in order, and it is possible to control individual process state via an rpc mechanism, thus allowing ordinary users to restart processes. Description-md5: b18ffbeaa3a697e8ccaee9cc104ec380 Homepage: http://supervisord.org/ Bugs: https://bugs.launchpad.net/ubuntu/+filebug Origin: Ubuntu

Thanks

Running "supervisorctl reload" on a running supervisord instance will cause program to stop and not re-start.

I've noticed this happening since upgrading from 3.0a10 to 3.0a12. Can provide more information if it's not duplicatable.

https://pypi.python.org/pypi/supervisor

Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3.

Vs.

https://github.com/Supervisor/supervisor/blob/master/setup.py#L58-L61

https://github.com/Supervisor/supervisor/labels/python%203

I am trying to use supervisord to manage instances of playframework applications. The framework supplies commands for starting and stopping instances which allows an application to properly shutdown and the execution of lifecycle events of plugins. An example is the proper closing of Lucene search index, which cannot be opened again if they are shutdown ungracefully, because a "write-lock" file remains the in index directory.

What I would consider a great addition, would be the possibility to specify something like this:

[program:my-play-web-app] command=/opt/play-1.2.5/play start stop-command=/opt/play-1.2.5/play stop directory=/path/to/home-of-play-web-app/

Is there any means that I can do this with supervisord right now? The only workaround I have found is the following:

[program:my-play-web-app] command=/path/to//home-of-play-web-app/startup.sh directory=/path/to/home-of-play-web-app/

With startup.sh being:

trap "{ echo Stopping play app; /opt/play-1.2.5/play stop; exit 0; }" EXIT echo Starting play app /opt/play-1.2.5/play start

(taken from here: http://stackoverflow.com/questions/7732371/how-to-properly-manage-rabbitmq-with-supervisord )

[root@ip-10-245-174-225] ~ $ supervisorctl stop XXX ^CTraceback (most recent call last): File "/usr/local/bin/supervisorctl", line 9, in load_entry_point('supervisor==3.0a12', 'console_scripts', 'supervisorctl')() File "/usr/local/lib/python2.6/dist-packages/supervisor/supervisorctl.py", line 1114, in main c.onecmd(" ".join(options.args)) File "/usr/local/lib/python2.6/dist-packages/supervisor/supervisorctl.py", line 144, in onecmd return do_func(arg) File "/usr/local/lib/python2.6/dist-packages/supervisor/supervisorctl.py", line 732, in do_stop result = supervisor.stopProcess(name) File "/usr/lib/python2.6/xmlrpclib.py", line 1199, in call return self.__send(self.__name, args) File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/local/lib/python2.6/dist-packages/supervisor/xmlrpc.py", line 463, in request r = self.connection.getresponse() File "/usr/lib/python2.6/httplib.py", line 990, in getresponse response.begin() File "/usr/lib/python2.6/httplib.py", line 391, in begin version, status, reason = self._read_status() File "/usr/lib/python2.6/httplib.py", line 349, in _read_status line = self.fp.readline() File "/usr/lib/python2.6/socket.py", line 427, in readline data = recv(1) KeyboardInterrupt

supervisorctl status show 'STOPPED' and the process does not exists. The log file shows: 2012-06-19 14:31:08,722 INFO stopped: XXX (terminated by SIGTERM)

I can turn on more debugging if you need

I wrote a Python script for outputting "%H:%M:%S" each second. Then, I used tail -f function on both supervisorctl and Web interface. Unfortunately it didn't work

For supervisorctl, it output a data chunk including error message, then stopped:

supervisor> status
clock                            RUNNING   pid 21792, uptime 0:15:08
supervisor> tail -f clock
==> Press Ctrl-C to exit <==
b':29:33\n21:29:34\n21:29:35\n21:29:36\n21:29:37\n21:29:38\n21:29:39\n21:29:40\n21:29:41\n21:29:42\n21:29:43\n21:29:44\n21:29:45\n21:29:46\n21:29:47\n21:29:48\n21:29:49\n21:29:50\n21:29:51\n21:29:52\n21:29:53\n21:29:54\n21:29:55\n21:29:56\n21:29:57\n21:29:58\n21:29:59\n21:30:00\n21:30:01\n21:30:02\n21:30:03\n21:30:04\n21:30:05\n21:30:06\n21:30:07\n21:30:08\n21:30:09\n21:30:10\n21:30:11\n21:30:12\n21:30:13\n21:30:14\n21:30:15\n21:30:16\n21:30:17\n21:30:18\n21:30:19\n21:30:20\n21:30:21\n21:30:22\n21:30:23\n21:30:24\n21:30:25\n21:30:26\n21:30:27\n21:30:28\n21:30:29\n21:30:30\n21:30:31\n21:30:32\n21:30:33\n21:30:34\n21:30:35\n21:30:36\n21:30:37\n21:30:38\n21:30:39\n21:30:40\n21:30:41\n21:30:42\n21:30:43\n21:30:44\n21:30:45\n21:30:46\n21:30:47\n21:30:48\n21:30:49\n21:30:50\n21:30:51\n21:30:52\n21:30:53\n21:30:54\n21:30:55\n21:30:56\n21:30:57\n21:30:58\n21:30:59\n21:31:00\n21:31:01\n21:31:02\n21:31:03\n21:31:04\n21:31:05\n21:31:06\n21:31:07\n21:31:08\n21:31:09\n21:31:10\n21:31:11\n21:31:12\n21:31:13\n21:31:14\n21:3http://127.0.0.1:9001/logtail/clock/stdout Cannot connect, error: <class 'ValueError'> (invalid literal for int() with base 16: "1:15\\n21:31:16\\n21:31:17\\n21:31:18\\n21:31:19\\n21:31:20\\n21:31:21\\n21:31:22\\n21:31:23\\n21:31:24\\n21:31:25\\n21:31:26\\n'")
supervisor> 

Take a look at the output, you will see the error message:

http://127.0.0.1:9001/logtail/clock/stdout Cannot connect, error: <class 'ValueError'> (invalid literal for int() with base 16: "1:15\\n21:31:16\\n21:31:17\\n21:31:18\\n21:31:19\\n21:31:20\\n21:31:21\\n21:31:22\\n21:31:23\\n21:31:24\\n21:31:25\\n21:31:26\\n'"

For Web interface, sometimes it behaved same as supervisorctl, sometimes it didn't show any log.

With this fix, supervisor worked perfectly with Python-2.7.8 and Python-3.4.1

Perhaps I missed it but is there a good explanation anywhere as to the differences between these four commands? I didn't see them discussed in the supervisord online documentation. I've noticed on ServerFault and Stackoverflow that other users don't understand their differences either.

For example, if I change the configuration in one program section, I know I must do "supervisorctl reread" to have those changes made available. But how do you restart just that one program? supervisorctl restart doesn't work. Instead if appears that you must either run "supervisorctl update" or restart the supervisor daemon itself. However, this seems to have the unintended effect of restarting all programs, not just the one that changed.

Thanks.

Hi there, thanks for the recent rework in the syslog support. This is a set of changes which make the syslog output a bit better, reaching this:

    Sep 19 10:18:46.285916 Herman daemon.notice supervisord[5296]: supervisord started with pid 5296
    Sep 19 10:18:47.288994 Herman daemon.notice supervisord[5296]: spawned: 'vmstat' with pid 5299
    Sep 19 10:18:47.291366 Herman daemon.notice supervisord[5296]: spawned: 'badvmstat' with pid 5300
    Sep 19 10:18:47.297447 Herman   user.info   vmstat: procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
    Sep 19 10:18:47.298812 Herman   user.info   vmstat:  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
    Sep 19 10:18:47.299112 Herman   user.info   vmstat:  3  0      0 4874284 244368 1695416    0    0    63    20   62  191  1  0 98  1
    Sep 19 10:18:47.299428 Herman   user.notice badvmstat: vmstat: failed to parse argument: '5;'
    Sep 19 10:18:47.299866 Herman daemon.notice supervisord[5296]: exited: badvmstat (exit status 1; not expected)
    Sep 19 10:18:48.298243 Herman   user.info   vmstat:  0  0      0 4863852 244368 1702904    0    0     0     0 1437 8074  4  3 93  0
    Sep 19 10:18:48.298447 Herman daemon.notice supervisord[5296]: success: vmstat entered RUNNING state, process has stayed up for > than 1 seconds (startse
    Sep 19 10:18:49.298594 Herman   user.info   vmstat:  0  0      0 4863528 244368 1703152    0    0     0     0  737 1475  1  1 99  0
      ...
    Sep 19 10:19:13.488894 Herman daemon.warning supervisord[5296]: received SIGINT indicating exit request

Along the lines of the new "stdout_syslog" and "stderr_syslog" boolean values, I have created a new "syslog" top-level configuration, which is configured identically. Additionally, there are now reasonable defaults for syslog facility and priority (shown in the above, but not logged by default by eg rsyslog). Finally, if you care, you can select the syslog channel (192 to choose from!) yourself for each stream by putting the channel there instead of "true" in any of the *syslog config settings.

Closes issue #162

I want to use the exit code for nagios but it's allways 0.

ecample 1: zope@plone:~> ./bin/supervisorctl status http://127.0.0.1:9001 refused connection zope@plone:~> echo $? 0

Could you change exit LSB conform ? http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

example 2: ./bin/supervisorctl status balancer RUNNING pid 23753, uptime 0:00:50 instance0 RUNNING pid 23751, uptime 0:00:50 instance1 EXITED Jun 26 05:40 PM varnish RUNNING pid 23754, uptime 0:00:50 zeo RUNNING pid 23750, uptime 0:00:50 zope@plone:~> echo $? 0

I would like to keep my environment variables out the the supervisord.conf file for security reasons (I keep the supervisord.conf under version control. I've looked at the documentation and I don't see any way of doing this with supervisor. Am I missing something?

Hi, There are multiple warnings with recent setuptools versions:

/usr/lib/python3.10/site-packages/setuptools/command/build_py.py:202: SetuptoolsDeprecationWarning:     Installing 'supervisor.scripts' as data is deprecated, please list it in `packages`.                       
    !!                                                                                                                                                                                                             
                                                                                                                                                                                                                   
                                                                                                                                                                                                                   
    ############################                                                                                                                                                                                   
    # Package would be ignored #                                                                                                                                                                                   
    ############################                                                                                                                                                                                   
    Python recognizes 'supervisor.scripts' as an importable package,                                                                                                                                               
    but it is not listed in the `packages` configuration of setuptools.                                                                                                                                            
                                                                                                                                                                                                                   
    'supervisor.scripts' has been automatically added to the distribution only                                                                                                                                     
    because it may contain data files, but this behavior is likely to change                                                                                                                                       
    in future versions of setuptools (and therefore is considered deprecated).                                                                                                                                     
                                                                                                                                                                                                                   
    Please make sure that 'supervisor.scripts' is included as a package by using                                                                                                                                   
    the `packages` configuration field or the proper discovery methods                                                                                                                                             
    (for example by using `find_namespace_packages(...)`/`find_namespace:`                                                                                                                                         
    instead of `find_packages(...)`/`find:`).                                                                                                                                                                      
                                                                                                                                                                                                                   
    You can read more about "package discovery" and "data files" on setuptools                                                                                                                                     
    documentation page.                                                                                                                                                                                            
                                                                                                                                                                                                                   
                                                                                                                                                                                                                   
!!

All these have the same issue:

Installing 'supervisor.scripts' as data is deprecated, please list it in `packages`.                      
Installing 'supervisor.skel' as data is deprecated, please list it in `packages`.                         
Installing 'supervisor.tests.fixtures' as data is deprecated, please list it in `packages`.               
Installing 'supervisor.tests.fixtures.example' as data is deprecated, please list it in `packages`.       
Installing 'supervisor.ui' as data is deprecated, please list it in `packages`.                           
Installing 'supervisor.ui.images' as data is deprecated, please list it in `packages`.                    
Installing 'supervisor.ui.stylesheets' as data is deprecated, please list it in `packages`.               

Hi,

I fall down this problem recently.

If an env var contains # SOMETHING # the parsing fails.

No idea if it is related to the # or the multi lines.

$ more supervisord.conf
[supervisord]
nodaemon = true
loglevel = debug

[program:printenv]
command = /bin/bash -c 'env | sort | grep FOO_'
environment =
    FOO_1=BAR_1, 
    FOO_2="# A #",
    FOO_3=BAR_3
startsecs = 0
autorestart = false 

$ supervisord -v
4.2.2
$ supervisord -c supervisord.conf
Error: No closing quotation in section 'program:printenv' (file: 'supervisord.conf')
For help, use /nobackup/lvalls1/valls/Software/miniconda3/envs/tomodemo-tools-env/bin/supervisord -h

If a process redirects stdout, supervisord creates a pipe and watchs for READ event on the pipe. If the readfd() fails due to some error(in my case it's OutOfMemory exception), the pipe will be removed from the poll list but the FD is not closed. This means the pipe has no reader and the process will block forever when writing something to stdout.

It seems supervisor could either ignore such errors and retry or just close the pipe to let the child get EPIPE on writing to stdout

I'd like to see if a process should be restarted when displaying the status. It's easy to forget to reread the configuration file after modifying it. In such case, the user try to restart it and does not understand why the changes are not used.

Currently, the output is:

supervisor> status
demo                             RUNNING   pid 16371, uptime 0:02:43
demo2                            RUNNING   pid 16372, uptime 0:02:43

It could be something like:

supervisor> status
demo                             RUNNING  changed pid 16371, uptime 0:02:43
demo2                            RUNNING  -       pid 16372, uptime 0:02:43

Adding such info would break the backward compatibility if scripts parse the output. To address this new problem, a configuration could be added to set the output of status in /etc/supervisor/supervisord.conf file. I think about two ways to implement it:

• 1. a boolean (called like changedstatus) to insert/ignore this data. By default, it must be disabled (for backward compatibility).
• 2. a list (called like statusline) to set up data displayed and their order. For example, with name,pid,status, a line will be like:

demo                             pid 16371, uptime 0:02:43  RUNNING

By default, it would be equivalent to statusline=name,status,pid (for backward compatibility).

IMO, Solution 2 is better because it's more versatile and allows to add new data in the future if needed.

Another way would be to add a new command to do that but the general usage of supervisorctl will be less clear so I think it's solution 2 is better than this one too.

What do you think about:

• the idea to add the changed data in status command?
• the way to implement backward compatibility?

I'm interested to make the PRs to implement it.

So Im troubleshooting a problem with log rotation on a server.. what's happening is that when logrotate is called a midnight the supervisord.log is not rotating correctly. I end up with a *.log.1, *.log.2 and so on. But the supervisord process is not moving to the new log file. If I restart the daemon or run supervisorctl update or restart then it does. I believe the problem lies with logrotate however in researching logging and rotations with supervisord I'm left with more questions than answers. The log files in question: /var/log/cloudbolt/supervisord.log are owned by apache:apache and lsof shows supervisord as the only pid writing to them. Does Supervisord rely upon logrotate or does it perform it's own rotations?

Environment Details: CentOS 7 Supervisord 4.2.2 Logrotate 3.8.6

supervisord.conf:

[unix_http_server]
file=/var/run/cloudbolt/supervisor.sock   ; the path to the socket file

[supervisord]
logfile=/var/log/cloudbolt/supervisord.log ; main log file; default $CWD/supervisord.log
logfile_maxbytes=50MB        ; max main logfile bytes b4 rotation; default 50MB
logfile_backups=10           ; # of main logfile backups; 0 means none, default 10
loglevel=trace                ; log level; default info; others: debug,warn,trace
pidfile=/var/run/cloudbolt/supervisord.pid ; supervisord pidfile; default supervisord.pid
nodaemon=false               ; start in foreground if true; default false
minfds=786068
minprocs=200                 ; min. avail process descriptors;default 200

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

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

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

The only file under /etc/supervisord.d/ - jobengine.conf

[program:jobengine]
; Set full path to Job Engine program if using virtualenv
command=python /opt/cloudbolt/jobengine/jobengine.pyc --namespace=worker%(process_num)02d
environment=PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:

directory=/opt/cloudbolt
user=root
numprocs=4
process_name=%(process_num)01d
stdout_logfile=/var/log/cloudbolt/jobengine.log
stderr_logfile=/var/log/cloudbolt/jobengine.log
autostart=true
autorestart=true
startsecs=10
startretries=999

; Need to wait for currently executing tasks to finish at shutdown.
; Increase this if you have very long running tasks.
stopwaitsecs = 590

; Causes supervisor to send the termination signal (SIGTERM) to the whole process group.
stopasgroup=true

; default (999)
priority=999

Thanks!!