Tag Info

Hot answers tagged

58

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: supervisorctl reread supervisorctl update


32

There is a plugin called superlance. You install it with pip install superlance or download it at: http://pypi.python.org/pypi/superlance The next thing you do is you go into your supervisord.conf and add the following lines: [eventlistener:crashmail] command=/usr/local/bin/crashmail -a -m email1@example.com events=PROCESS_STATE This should be followed ...


20

You could use sudo in place of your custom script to accomplish the same thing. That is, given the default supervisord configuration, in which only root can run supervisorctl, you could put an entry like this into /etc/sudoers: alice ALL = (root) NOPASSWD:/usr/bin/supervisorctl restart app1 bob ALL = (root) NOPASSWD:/usr/bin/supervisorctl restart app2 ...


16

I had the same issue, a sudo service supervisord reload did the trick, though I don't know if that is the answer to your question.


13

I created an upstart script for ubuntu 9.10 For example I installed supervisor into a virtual environment, then start and control supervisor from upstart. create a text file /etc/init/supervisord.conf the contents are: description "supervisord" start on runlevel [345] stop on runlevel [!345] expect fork respawn exec ...


12

This is what I use on RHEL 5.4 and CentOS 5.5 I'm not sure wether it's depending on some configuration settings in my supervisord.conf. But it seems to work OK. You need to run the following command after installing it chkconfig --add supervisord [/etc/rc.d/init.d/supervisord] #!/bin/sh # # /etc/rc.d/init.d/supervisord # # Supervisor is a client/server ...


12

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: root@debian:~# supervisorctl reread gunicorn: changed Then, simply reload that ...


10

Ah, you use supervisorctl start groupname:* I discovered this by typing just supervisorctl start and being told: Error: start requires a process name start <name> Start a process start <gname>:* Start all processes in a group start <name> <name> Start multiple processes or groups start all Start all processes ...


9

Cron periodically calling a shell script to ensure a service is running is actually a pretty decent entry-level method for service monitoring on simple networks. Cron can check once per minute, so that may be good enough for the demands of your environment if downtimes of < 60 seconds is acceptable. It's easy to set up and use. Supervisor, on the other ...


6

If gunicorn_django is daemonizing itself, it's not the kind of program supervisor is designed to manage. Supervisor expects its supervised programs to run in the foreground so it can monitor if they've exited. See supervisord docs.


5

I'd use lsof to find out what process is listening on those ports. lsof -i tcp | grep LISTEN Once you've worked out what process it is, that's half the battle.


5

There is a Debian/Ubuntu script in official Supervisor GitHub repo: https://github.com/Supervisor/initscripts/blob/master/debian-norrgard


5

Thanks to Mark for the link to that script; here is my working example for CentOS: #!/bin/bash # Source: https://confluence.atlassian.com/plugins/viewsource/viewpagesrc.action?pageId=252348917 function shutdown() { date echo "Shutting down Tomcat" unset CATALINA_PID # Necessary in some cases unset LD_LIBRARY_PATH # Necessary in some cases ...


5

The --config option must be specified before the sentry subcommand, like so: sentry --config=/somedir/sentry.conf.py start ....


5

I've just stumbled across the same issue, so I'll leave the reasons it happened to me. We had supervisor installed into the global path (not a virtualenv) using pip, which meant we were running the latest version. However, this is undesirable from a server maintenance point of view, so we switched the older version in Apt. pip uninstall doesn't clear up ...


5

http://supervisord.org/configuration.html#program-x-section-settings says "Values containing non-alphanumeric characters should be placed in quotes"


5

This feature has been added to Supervisor recently environment=PATH="/home/site/environments/master/bin:%(ENV_PATH)s" https://github.com/Supervisor/supervisor/blob/master/supervisor/skel/sample.conf#L8 See also https://stackoverflow.com/questions/12900402/supervisor-and-environment-variables


5

Honestly, the workers_per_application is more of a performance tweak to ensure your application can consume 100% of the CPU at any time. It does not mean that it will. You can configure all of your applications to have 9 workers... as long as you keep in mind that there is a potential that one application could be working on something very difficult which ...


5

You shouldn't be running your gunicorn server as root, just think if someone found an exploit in your code can do anything to the server. Put the pidfile in /tmp or /var/tmp and run as a non privileged user.


5

That's the whole idea, to use systemd (or upstart etc) inside a container. Docker is used most of the time to run a single service per container, so for a complex site you would need a container for the web server and another one for the database server. With a process manager you could run both in the same container. Which approach is better is ...


5

The command you provide should use the python binary inside the virtual environment: command = /home/user/Sites/my-site/venv/bin/python /home/user/Sites/my-site/app.py


4

This is pretty well covered in the Supervisord intro chapter. Most services will run/work just fine with init.d, and that will be their default, out-of-the-box config. The process managers exist to give you expanded and finer-grained control and monitoring of your critical processes and services if that is something you desire/require.


4

Try creating the log files and using chown to change the ownership to the appropriate user. If possible change the log location to a subdirectory owned by the appropriate user. I use logrotate to rotate logs periodically. It can handle permissions when rotating logs.


4

In order to deal with the problem, we'll need some program running in foreground, which exits whenever the daemon exits, and which also proxies signals to the daemon. Consider using the following script bash script: #! /usr/bin/env bash set -eu pidfile="/var/run/your-daemon.pid" command=/usr/sbin/your-daemon # Proxy signals function kill_app(){ kill ...


4

You're probably missing the [supervisord] section in the file. See this.


4

The problem is the --preload parameter. The first solution is not to use the --preload. The second solution is to follow this: # Reload a new master with new workers kill -s USR2 $PID # Graceful stop old workers kill -s WINCH $OLDPID # Graceful stop old master kill -s QUIT $OLDPID The third solution is to use the package ...


4

It sounds to me like what your actually looking for is closer to cron. I'm not familiar with supervisor but from the description provided here, it sounds it is trying to be a userspace replacement for certain aspects of init. By this I mean that it focuses in providing: start/stop/restart of services(programs) Automatic program crash detection and restart ...


4

I figured it out. I didn't have the supervisord section in the config file. When it said .ini file, it threw me off.



Only top voted, non community-wiki answers of a minimum length are eligible