There should be some way to configure a URL prefix for when the web interface is behind a proxy. This has been requested several times on the mailing list.

Related to issue #28

The file /etc/supervisor.conf exists but I have no read permissions. However,

$ supervisorctl -c /etc/supervisor.conf 
Error: could not find config file /etc/supervisor.conf
For help, use /usr/bin/supervisorctl -h

gives me. I would say this is a somehow untrue error since the file actually exists.

2011-12-07 22:11:53,879 CRIT unknown problem killing openvpn (12796):Traceback (most recent call la
st):
File "/home/work/opt/py2.7/lib/python2.7/site-packages/supervisor-3.0a10-py2.7.egg/supervisor/pro
cess.py", line 384, in kill
options.kill(self.pid, sig)
File "/home/work/opt/py2.7/lib/python2.7/site-packages/supervisor-3.0a10-py2.7.egg/supervisor/opt
ions.py", line 1116, in kill
os.kill(pid, signal)
OSError: [Errno 1] Operation not permitted

then supervisord quit.
then running program is a setuid program.

or if I can provid a personalized kill command

If the combined length of the supervisor username + password is greater than 56 characters, supervisorctl tail -f won't work:

$ supervisorctl tail -f program
==> Press Ctrl-C to exit <==
unix:///tmp/supervisor.sock/logtail/program/stdout Cannot read, status code 401

This happens with both unix and http sockets, and every other configuration combination I've tried.

I've put a sample config (and test program) here: https://gist.github.com/1021475 -- with that configuration, tail -f fails as it's currently written, but succeeds if I remove one character from either the username or password, bringing the combined length down from 57 to 56.

Tested against both the 3.0a10 release and the master branch at github (at commit c7b8902).

Here is the procedure to reproduce the issue:

1. script.sh is owned by the "ubuntu" user
2. A change in Chef is made to change the owner to "root"
3. Supervisorctl is reloaded and the process is manually restarted

The root user is designated to run the command in the process configuration file. Even after the changes, "ubuntu" is running the script.

You can specify a local configuration file when launching the daemon. However, if you edit the local config file and use supervisorctl -c local_config.conf to restart the services, the changes made to the local config file are ignored.

To see the effect you must restart the supervisor daemon.

Hi,

I would auto start supervisor when my server start.
I need to configure an init.d supervisor script.

To do that, I need to search it in Google.

Suggestion, append this init.d script in supervisor package or in documentation.

Regards,
Stephane

I hacked the riak running script and let it export a pid file when I run 'riak start'
then I use the following conf
"
[program:riak]
command=pidproxy /var/run/riak.pid riak start
autostart=true
autorestart=true
stdout_logfile= supervisord.log
redirect_stderr=true
"
it seems the pidproxy doesn't help, supervisord still trying start riak as many time as it could and then reports "fetal error"

Please help. thanks a lot.

[inet_http_server]
port=*:2700

http response 500, and i start supervisord --loglevel debug, at supervisord.log have no debug info when http response 500.

the old version(3.0a9) was normal.

os ubuntu 11.10, or python2.7 platform.

I'm running redis with supervisord. (As of the current version) Redis doesn't save its database when it receives a TERM signal (or any other signal). This could be circumvented by having a pre-stop hook that could be used to run a command to save the database before sending the TERM signal.

I assume that this would be a useful feature for other use cases, too, so I'm proposing to add pre-start, post-start, post-start and pre-stop hooks to supervisord.

This issue came out of a discussion[1,2] on the supervisor-users mailing list.

When trying to connect remotely using supervisorctl I get

$ supervisorctl -s http://myserver:9001
Error: No config file found at default paths (/usr/local/etc/supervisord.conf, /usr/local/supervisord.conf, supervisord.conf, etc/supervisord.conf, /etc/supervisord.conf); use the -c option to specify a config file at a different path
For help, use /usr/local/bin/supervisorctl -h

My server does not have any password or anything like that, and I can access the server through my web browser.

To overcome this problem I need to create an empty configuration file with the following content:

[supervisorctl]

and then use it when invoking supervisorctl:

$ supervisorctl -c mysupervisor.conf -s http://myserver:9001
my_process                     RUNNING    pid 7385, uptime 2 days, 15:45:40
supervisor> 

My proposal is to not require a configuration file when server is given by command line. I consider this a bug.

[1] http://lists.supervisord.org/pipermail/supervisor-users/2011-December/000991.html
[2] http://lists.supervisord.org/pipermail/supervisor-users/2011-December/000993.html

logfile:
^[[31m^[[7memergency^[[0m: Master DOWN!

error: <class 'xml.parsers.expat.ExpatError'>, not well-formed (invalid token): line 51, column 39: file: /usr/lib/python2.6/xmlrpclib.py line: 601

ok, if an application has a problem and then you click on the link to do a "tail", you only see like 15 lines which is almost useless.

You could consider going to the stderr log file that supervisord creates, but that's owned by supervisord and I can't even read.

So here are some options to make looking at log content actually useful:

1. Mod supervisord to have another html link per process named "view stderr" or "view stdout" .. when clicked these would display the content of the corresponding log file on an html page
2. Alter supervisord to allow the user to specify on startup how many lines to pass to "tail -f" .. so when one clicks that link in the supervisord UI, you get more than the current 15 or so lines
3. On the html page in which supervisord shows tail's output, add an html button titled "go back more" that, when clicked, stops the tail, and restarts it, but passes it a larger number than before so more content is shown (alternatively you could have a text box there that lets the user enter how many lines they'd like to go back and see)

If I download the supervisor tarball, extract it, prune the .egg-info directory, and run easy_install on it, a bunch of files are missing from the result, resulting in a useless supervisor bundle.

Here's a diff showing all the files present in SOURCES.txt in the provided .egg-info directory, but not in the SOURCES.txt generated by easy_install. It's basically all the files not ending with .py.

diff -dur supervisor.egg-info/SOURCES.txt /home/adar/Downloads/supervisor-3.0a12/supervisor.egg-info/SOURCES.txt
--- supervisor.egg-info/SOURCES.txt 2011-12-15 00:13:26.565119261 -0800
+++ /home/adar/Downloads/supervisor-3.0a12/supervisor.egg-info/SOURCES.txt 2011-12-06 17:16:32.000000000 -0800
@@ -1,5 +1,33 @@
+.gitignore
+CHANGES.txt
+COPYRIGHT.txt
+HISTORY.txt
+LICENSES.txt
+PLUGINS.rst
+README.rst
+TODO.txt
setup.cfg
setup.py
+tox.ini
+docs/Makefile
+docs/api.rst
+docs/conf.py
+docs/configuration.rst
+docs/development.rst
+docs/events.rst
+docs/faq.rst
+docs/glossary.rst
+docs/index.rst
+docs/installing.rst
+docs/introduction.rst
+docs/logging.rst
+docs/running.rst
+docs/subprocess-transitions.png
+docs/subprocess.rst
+docs/upgrading.rst
+docs/xmlrpc.rst
+docs/.static/logo_hi.gif
+docs/.static/repoze.css
supervisor/init.py
supervisor/childutils.py
supervisor/confecho.py
@@ -17,6 +45,7 @@
supervisor/states.py
supervisor/supervisorctl.py
supervisor/supervisord.py
+supervisor/version.txt
supervisor/web.py
supervisor/xmlrpc.py
supervisor.egg-info/PKG-INFO
@@ -27,6 +56,13 @@
supervisor.egg-info/not-zip-safe
supervisor.egg-info/requires.txt
supervisor.egg-info/top_level.txt
+supervisor/medusa/CHANGES.txt
+supervisor/medusa/INSTALL.txt
+supervisor/medusa/LICENSE.txt
+supervisor/medusa/MANIFEST
+supervisor/medusa/Makefile
+supervisor/medusa/README.txt
+supervisor/medusa/TODO.txt
supervisor/medusa/init.py
supervisor/medusa/asynchat_25.py
supervisor/medusa/asyncore_25.py
@@ -57,6 +93,48 @@
supervisor/medusa/unix_user_handler.py
supervisor/medusa/virtual_handler.py
supervisor/medusa/xmlrpc_handler.py
+supervisor/medusa/debian/changelog
+supervisor/medusa/debian/control
+supervisor/medusa/debian/copyright
+supervisor/medusa/debian/postinst
+supervisor/medusa/debian/prerm
+supervisor/medusa/debian/rules
+supervisor/medusa/demo/publish.py
+supervisor/medusa/demo/script_server.py
+supervisor/medusa/demo/simple_anon_ftpd.py
+supervisor/medusa/demo/start_medusa.py
+supervisor/medusa/demo/winFTPserver.py
+supervisor/medusa/docs/README.html
+supervisor/medusa/docs/async_blurbs.txt
+supervisor/medusa/docs/composing_producers.gif
+supervisor/medusa/docs/data_flow.gif
+supervisor/medusa/docs/data_flow.html
+supervisor/medusa/docs/debugging.txt
+supervisor/medusa/docs/producers.gif
+supervisor/medusa/docs/programming.html
+supervisor/medusa/docs/proxy_notes.txt
+supervisor/medusa/docs/threads.txt
+supervisor/medusa/docs/tkinter.txt
+supervisor/medusa/test/asyn_http_bench.py
+supervisor/medusa/test/bench.py
+supervisor/medusa/test/max_sockets.py
+supervisor/medusa/test/test_11.py
+supervisor/medusa/test/test_lb.py
+supervisor/medusa/test/test_medusa.py
+supervisor/medusa/test/test_producers.py
+supervisor/medusa/test/test_single_11.py
+supervisor/medusa/test/tests.txt
+supervisor/medusa/thread/pi_module.py
+supervisor/medusa/thread/select_trigger.py
+supervisor/medusa/thread/test_module.py
+supervisor/medusa/thread/thread_channel.py
+supervisor/medusa/thread/thread_handler.py
+supervisor/scripts/loop_eventgen.py
+supervisor/scripts/loop_listener.py
+supervisor/scripts/sample_commevent.py
+supervisor/scripts/sample_eventlistener.py
+supervisor/scripts/sample_exiting_eventlistener.py
+supervisor/skel/sample.conf
supervisor/tests/init.py
supervisor/tests/base.py
supervisor/tests/test_childutils.py
@@ -75,4 +153,20 @@
supervisor/tests/test_supervisord.py
supervisor/tests/test_web.py
supervisor/tests/test_xmlrpc.py
-supervisor/tests/trackrefs.py
\ No newline at end of file
+supervisor/tests/trackrefs.py
+supervisor/tests/fixtures/donothing.conf
+supervisor/tests/fixtures/fakeos.py
+supervisor/tests/fixtures/spew.py
+supervisor/tests/fixtures/unkillable_spew.py
+supervisor/ui/status.html
+supervisor/ui/tail.html
+supervisor/ui/images/button_refresh.gif
+supervisor/ui/images/button_restart.gif
+supervisor/ui/images/button_stop.gif
+supervisor/ui/images/rule.gif
+supervisor/ui/images/state0.gif
+supervisor/ui/images/state1.gif
+supervisor/ui/images/state2.gif
+supervisor/ui/images/state3.gif
+supervisor/ui/images/supervisor.gif
+supervisor/ui/stylesheets/supervisor.css
\ No newline at end of file

I would be a an improved user experience if the interface could automatically reload from time to time. I'm getting tired of updating the page the first thing I do every time I load supervisor in my browser.

Heath Kehoe provides this analysis:

The problem with losing subprocess stdout/stderr when the subprocess is
stopped is caused by the self.drain() call in Subprocess::stop(). If I
remove the drain() call from the stop() method, the problem is fixed.

Here's why: The drain() method ends up calling handle_read_event() for
the POutputDispatcher instances connected to stdout and stderr (because
their readable() methods always return True while the pipe is still
open). So readfd() is called which will return an empty string because
there very likely isn't any data pending; and that causes
handle_read_event() to close the pipe. But the process is still running,
and about receive its stop signal, so any output it wants to generate
between getting the signal and exiting will be lost (and worse, if the
subprocess generates more than a little output, it may receive a
SIGPIPE. If it wasn't written to handle or ignore that signal, it'll
terminate uncleanly).

Since drain() is called again during Subprocess::finish(), which happens
after the process has actually exited, there's no need to call drain()
earlier.

Hi,

it seems that the supervisord source code is now hosted here on github. The bugtracker too.

But the doc (visible at http://supervisord.org/development.html and available in the docs/ directory in this repository) still indicated that the code is located at http://svn.supervisord.org/ and the bugtracker at http://www.plope.com/software/collector.

Could it be corrected?

Thanks.

With the first config process starts with effective UID=0. With the second UID set as expected. Effective GID set as expected in both cases.

Using v3.0a8 packaged in Debian stable (squeeze).

[program:example]
user = %(program_name)s
group = %(program_name)s
command = /home/%(program_name)s/bin/django-admin.py run_gunicorn --settings=src.settings --log-level=info --workers=1 -b unix:/var/local/projects/%(program_name)s.sock
autostart = true
redirect_stderr = true
stdout_logfile = /var/log/supervisor/%(program_name)s.log

[program:example]
user = example
group = %(program_name)s
command = /home/%(program_name)s/bin/django-admin.py run_gunicorn --settings=src.settings --log-level=info --workers=1 -b unix:/var/local/projects/%(program_name)s.sock
autostart = true
redirect_stderr = true
stdout_logfile = /var/log/supervisor/%(program_name)s.log

Hi,
I may be mistaken but how can I tell supervisor to reread the processes configuration and start/stop services with the XMLRPC interface ?
I am looking for the equivalent of "supervisorctl update"

Distribution: Ubuntu-Server Stable
Python: 2.6

supervisord.conf

[inet_http_server]
port=127.0.0.1:9001

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

PHP-Script using Zend XmlRpcClient

I am using supervisor to daemonize php script with php cli. In my script I'm intercepting SIG_TERM signals to terminate the script safelt. After getting SIG_TERM the script echoes some data to output.

When I stop the script from superuserctl with stop command, the script successfully captures the term signal and shut downs gracefully but no data from output gets logged by supervisor after the stop command.

I was wondering if it's a bug or feature and how I can change this behavior.

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

Hi,
It may already be possible but I did not find anything leading me to think that.

Let's say I have three processes running: A, B and C and I want to add a new one D but without restarting A, B and C, is it possible currently ?

I am currently using daemontools and considering switching to supervisor but this is a feature I could hardly work without.

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.

In many cases optimal value for [program:x] numprocs is equal to number of CPUs visible to OS. Writing exact value may be not appropriate in cases where single config is used in a heterogeneous cluster with different number of cores on each box.

Here's info how to determine number of CPUs.
http://stackoverflow.com/questions/1006289/how-to-find-out-the-number-of-cpus-in-python

Sometimes you may want many similar program configurations. It'd be great if you could use "inheritance", like so

[program:foo-base]
; ... options ...
abstract = true

[program:foo1]
parent = foo-base

[program:foo2]
parent = foo-base

or like this

[program-template:foo-base]
; ... options ...

[program:foo1]
template = foo-base

Supervisor config:

[program:resque-scheduler]
startsecs=6
command=/opt/ruby-enterprise/bin/rake resque:scheduler
environment=RAILS_ENV=production
directory=/path/to/app/current
user=app_user
stderr_logfile = /var/log/supervisor/resque-scheduler.log
stdout_logfile = /var/log/supervisor/resque-scheduler.log

This is a typical Rails app, it took seconds to boot. That's why I use startsecs option.

There should only be 1 of this program running. But every time I restarted supervisord (/etc/init.d/supervisord restart), it spawned two of this rake resque:scheduler.

Are there any options I can use to make sure only 1 instance of program:x running?

Sometimes (for some reason not all the time), running sudo supervisorctl restart someservice returns:

<class 'xmlrpclib.Fault'>, <Fault 6: 'SHUTDOWN_STATE'>: file: /usr/lib/python2.6/xmlrpclib.py line: 838

In some odd cases this kills supervisord completely, printing "unix:///var/run/supervisor.sock no such file" whenever I run a command in supervisorctl manually. /etc/init.d/supervisor restart won't fix it, rather I need /etc/init.d/supervisor stop && /etc/init.d/supervisor start to get it back running.

I'm using supervisor 3.0a8 on Ubuntu 10.04.3 LTS (Kernel 2.6.32-21-server) 64bit.

Any idea how i can make the restart command not kill my supervisor and actually work?

Right now, if you start a process with supervisor, like the following

$ supervisorctl start foo

Then bring it in to the foreground

$ supervisorctl fg foo

It is currently not possible to use pdb from that foregrounded process. The process will just hang and no mention of pdb is shown in the foregrounded process.

Would it be possible to allow for a foreground process to interact with pdb?

Hi,

The %(here)s placeholder is very useful to set up processes relative to the config file path. However, %(here)s used in included configs resolve to the path of the main config, not the included one.

I suggest another placeholder called, let's say %(include_here)s, which would resolve to the path of the included config that contains it.

It would be very useful for the following scenario. I have a webapp which runs some background processes (consuming messages), there is a supervisord config in the repository of the webapp, that is included by the main config, so my /etc/supervisord.conf looks like:

; ... blabla
[include]
files = /var/www/config/supervisord_processes.ini

The supervisord_processes.ini contains the description of the processes of the webapp, so whenever I do a deployment, I just send a HUP to supervisord, reload the config and I have my background processes restarted with the new code.

The problem is that in the included config I have to use absolute path to my background processes. This is a little bit chaotic when working with several environments (devel, staging, production...) where the place where my code resides could be different.

This is why I need the %(include_here)s, to be able to refer to my processes relatively to the checkout path.

By the way, let me tell, I'm amazed by this project, it's really great and exactly was I was looking for.

Thank you for the help!

Supervisor's signal handler stores the received signal in a variable as opposed to a list. This means that (hypotheticall) if a SIGTERM arrives just before a SIGCHLD from a managed process, the SIGTERM can be orphaned.

The signal handler should add the received signal to a queue of some kind and handle_signal should process all of the signals in the queue.

I just ran a coverage analysis of the test cases and noted that tests/test_process.py: SubprocessTests. dont_test_spawn_and_kill is never executed because it does not follow the correct UnitTest naming convention. Removing prefix dont_ makes the test fail. Should it be removed?

This would allow to pass sensitive data in the arguments. It is often overkill to store these in separate configuration files, while it can be expressed as URI connection string (database or message broker connection), or username / password pair, as is often possible with many programs. I would expect that process_name to replace the default OS assigned one.

I'm using 'supervisor_ctl.onecmd("update")' to update a running supervisord process. After running for a while, I found that supervisord was using more and more memory. I used Heapy (see http://www.smira.ru/wp-content/uploads/2011/08/heapy.html) and a temporary backdoor in the web interface to figure out that supervisord was managing an array which kept growing, which had the following string in it:

         'Included extra file "..." during parsing'

I'm using a glob in the configuration, and it turns out that options.py writes the following:

                self.parse_warnings.append(
                    'Included extra file "%s" during parsing' % filename)

Since self.parse_warnings is not cleared between runs of the options parser, the array grows without bounds.

The simple fix is to clear self.parse_warnings at every parse_config() call. Other alternatives, like dropping the warnings entirely, or having reload initialize a new object, seem more invasive.

When a process has its stdout_logfile mistakenly set to a directory (instead of a file), it raises an exception during startup and ends up in an invalid state:

Traceback (most recent call last):
  File ".../supervisor/xmlrpc.py", line 65, in more
    value = self.callback()
  File ".../supervisor/rpcinterface.py", line 281, in startit
    process.spawn()
  File ".../supervisor/process.py", line 212, in spawn
    self.dispatchers, self.pipes = self.config.make_dispatchers(self)
  File ".../supervisor/options.py", line 1672, in make_dispatchers
    dispatchers[stdout_fd] = POutputDispatcher(proc, etype, stdout_fd)
  File .../supervisor/dispatchers.py", line 98, in __init__
    backups=backups)
  File ".../supervisor/options.py", line 434, in getLogger
    backups, stdout)
  File ".../supervisor/loggers.py", line 339, in getLogger
    handlers.append(RotatingFileHandler(filename,'a',maxbytes,backups))
  File ".../supervisor/loggers.py", line 170, in __init__
    self.stream = self.stream or open(filename, mode)
IOError: [Errno 21] Is a directory: '...'
2012-02-13 16:33:28,858 INFO success: ... entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
^C2012-02-13 16:40:25,063 WARN received SIGINT indicating exit request
2012-02-13 16:40:25,063 INFO waiting for ... to die
2012-02-13 16:40:29,062 INFO waiting for ... to die
2012-02-13 16:40:33,061 INFO waiting for ... to die
2012-02-13 16:40:37,061 INFO waiting for ... to die
2012-02-13 16:40:41,060 INFO waiting for ... to die

supervisor fails to shut down (waitpid(0, ...) returns -ECHILD repeatedly) and the only way to get going is to SIGKILL it and restart it.

supervisorctl status shows the process as:

... RUNNING    pid 0, uptime 0:03:24

which is clearly bogus.

Tested on git head as of commit 5d8a8bf.

Currently, supervisord supports only the non-standarized, now deprecated format: Windows-INI. The reason for supervisord to use the format is acknowledged: the parser is included in the Python's stdlib.

There's now a standarized format parser-serializer included in the Python's stdlib: JSON.

It will be nice if supervisord supports JSON as the configuration file (for the Python versions which support it, alongside with the legacy format). The reasons are:

• JSON is a standarized format (RFC 4627)
• The parser and serializer are included in Python's stdlib (starting from Python 2.6)
• People could generate (and edit) the configuration file with other tools or languages which have no support for the old format

The counter reason: JSON has no support for commenting.

I would like to suggest YAML, but it has no built-in support in Python

Actions like "Restart All" may be unreliable because they are implemented as simple GET requests. As these manipulate server state, I would recommend using form POST to initiate these.

I've looked at the sources concerning the [includes] conf section, and blatantly no check is done to prevent a user-owned file from being included by a root-owned file, and override main options or add processes launched with uid "root".

That's a real security concern (furthermore due to the possible use of file globs), shouldn't there be checks to ensure no low-security files (with wrong chmods, or non-root users) is included by a root-priviledged supervisord ?

I might help with that if a clear evolution is decided.

The web interface gives me

Error response

Error code 500.

Message: Internal Server Error.

Which really isn't giving me a lot to work with. It is properly asking for username/password, but as soon as I type the right one in it shows that error page.

http://lists.supervisord.org/pipermail/supervisor-users/2011-May/000913.html

$ supervisorctl status "appcontainer:*"
error: <class 'xmlrpclib.ProtocolError'>, <ProtocolError for
127.0.0.1/RPC2: 500 Internal Server Error>: file:
/usr/lib/pymodules/python2.6/supervisor/xmlrpc.py line: 474

The status command doesn't support the namespec syntax like start and stop. It probably should.

I can't get standard out from a supervisor controlled program, to show up in the logs. Could be a configuration issue, but I can't find the magic combination.

Here's a trivial demo using buildout to reproduce the issue, including a README.txt with instructions. Note that only the stderr log is ever written to, and if 'redirect_stderr=true' is uncommented in the config file, only stderr lands in the stdout log.

[email protected]:pbugni/supervisor_stdout_issue.git

(great tool, btw - thanks!)

http://lists.supervisord.org/pipermail/supervisor-users/2011-May/000906.html

My team at work has been using supervisord with great success for
the past 3 months in a production environment with 51 monitored
processes. Now we're testing a similar but larger iteration of
this work but with 203 monitored processes, and I believe we're
running into the same situation described below (web page gets
truncated at an arbitrary point of 65536 bytes, identical output
in curl's "Received" column that Drew described back in September.

Did anyone (maybe Drew?) find the issue or work around for this?
My platform details are:

• RHEL 5.5
• Supervisor 3.0a9
• Python from the xpyv-0.9.22-0.1.glibc2.5 (virtual python package)
• Python 2.6.1 (r261:67515, Jul 14 2009, 17:37:39)

Everything else (supervisor status, actual start/stop activity) is still
working perfectly. We just can't get a full listing of the processes
via the web UI.

Hey there,

great product, I'm using it for several tasks and it works nicely! Recently I wrote an additional module to provide another rpc interface. In my case however, I didn't store my new module in the PYTHONPATH (ie. sys.path). Obviously it couldn't be imported by supervisord unless I passed a modified PYTHONPATH environment variable to the supervisord process.

To simplify this, what do you think about adding an option to the [rpcinterface] sections that can be used to specify an additional PYTHONPATH element? The example from the documentation could look like this then:

[rpcinterface:another]
supervisor.rpcinterface_factory = my_module:make_another_rpcinterface
supervisor.pythonpath = /home/blah/development/my_another_rpcinterface

where /home/blah/development/my_another_rpcinterface would contain a my_module.py file defining the make_another_rpcinterface entry point.

I guess the implementation itself would be pretty simple; however, do you think this is a good idea? :D

I am not sure if this is something that should be reported to supervisor, or further to the Medusa project.

When opening up the frontpage of supervisor in Google Chrome (15.0.874.121) and/or Chromium (17.0.917.0 (Developer Build 106870 Linux) Ubuntu 10.04), certain *.gif files are being shown as "Pending" in "Network" listing of the developer tools. They are never downloaded.

The issue cannot be reproduced on Firefox.

Can anybody reproduce this?

When I "pip install supervisor", it succeeds with error message below.

Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 505, in run
self.__target(_self.__args, *_self.__kwargs)
File "/usr/lib/pymodules/python2.7/pip/index.py", line 245, in _get_queued_page
for link in page.rel_links():
File "/usr/lib/pymodules/python2.7/pip/index.py", line 516, in rel_links
for url in self.scraped_rel_links():
File "/usr/lib/pymodules/python2.7/pip/index.py", line 543, in scraped_rel_links
url = match.group(1) or match.group(2) or match.group(3)
IndexError: no such group

stopwaitsecs parameter gives "time to finish" to process. I'd like to have possibility to have infinite (eg: -1) stopwaitsecs which would result in just sending configured stopsignal and ignoring process response (lets say: if I asked to stop, application will stop...sooner or later).

Of course starting such application later could lead to issues, but this is expected.

What do you think about it?

Hi,

I have been trying to find a list of 3rd party plugins/eventlisteners/custom RPC interfaces for supervisor. How about adding one to the documentation/FAQ? Or the README? What do you think of this? I'd be willing to compile one (and make a pull request) if tell me where to put it.

Sheers,
Jens

I just executed python setup.py test and received one single failing test

[...]
test_update_not_on_shutdown (supervisor.tests.test_supervisorctl.TestDefaultControllerPlugin) ... ok
test_update_removed_procs (supervisor.tests.test_supervisorctl.TestDefaultControllerPlugin) ... ok
test_version (supervisor.tests.test_supervisorctl.TestDefaultControllerPlugin) ... ok

======================================================================
ERROR: test_main_profile (supervisor.tests.test_supervisord.EntryPointTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jens/src/Internal projects/supervisor/supervisor/tests/test_supervisord.py", line 53, in test_main_profile
    '--profile_options=cumulative,calls'], test=True)
  File "/home/jens/src/Internal projects/supervisor/supervisor/supervisord.py", line 358, in main
    profile('go(options)', globals(), locals(), sort_order, callers)
  File "/home/jens/src/Internal projects/supervisor/supervisor/supervisord.py", line 325, in profile
    import profile
ImportError: No module named profile

----------------------------------------------------------------------
Ran 710 tests in 1.600s

FAILED (errors=1)

I had no idea that the profile package was not included in the standard Python distribution. To try to come up with a patch to fix the problem, I've been searching the web all over to find the PyPi equivalent of the DEB package python-profiler, but can't find it. Does it exist? Should this test be considered a bug, or should we require every developer to install the Python DEB package for profile?

I currently can speak for other platforms that GNU/Linux Ubuntu/Debian. How do you install profile on MacOSX for example?

When I install the git repo version of supervisor 3.0a10, on OSX python2.6, the web page gives me an Error code 500. The pypi version via easy_install seems to work fine.

Supervisord uses select.select to monitor filehandles related to the processes it supervises. This is problematic because select.select raises a ValueError for filehandles numbered >1023. (Observed with supervisor 3.0a8 on an Ubuntu Gnu/Linux 11.04 amd64 machine.)

We ran into this problem when running approximately 254 supervised processes. Initially, we assumed it was a ulimit configuration problem, but found that the crash occurred even when running supervisord in non-daemon mode. I've been able to reproduce the stacktrace by supervising a large number of /bin/cat processes, and have included it below. Here's a conf file
to run 1100 cats:
https://gist.github.com/1068713

To reproduce this bug, just install that config file and run something like:
sudo bash -c "ulimit -n 10000; supervisord -n"

You'll see a ValueError (out of range) from select.select(), called from supervisord's runforever():
https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisord.py#L218

It appears this is a limitation of Python's select() function, which raises a ValueError on file descriptors > 1023. I've seen some suggestions that beyond this limit, one should use poll() instead of select(), but I'm not an expert.

FULL TRACEBACK:

Traceback (most recent call last):
File "/usr/bin/supervisord", line 9, in
load_entry_point('supervisor==3.0a8', 'console_scripts', 'supervisord')()
File "/usr/lib/pymodules/python2.7/supervisor/supervisord.py", line 371, in main
go(options)
File "/usr/lib/pymodules/python2.7/supervisor/supervisord.py", line 381, in go
d.main()
File "/usr/lib/pymodules/python2.7/supervisor/supervisord.py", line 94, in main
self.run()
File "/usr/lib/pymodules/python2.7/supervisor/supervisord.py", line 111, in run
self.runforever()
File "/usr/lib/pymodules/python2.7/supervisor/supervisord.py", line 229, in runforever
r, w, x = self.options.select(r, w, x, timeout)
File "/usr/lib/pymodules/python2.7/supervisor/options.py", line 1097, in select
return select.select(r, w, x, timeout)
ValueError: filedescriptor out of range in select()