Hot answers tagged supervisord
The difference is that upstart is an init replacement whereas supervisord is a Process Control System. This explanation is given on the supervisord site: It shares some of the same goals of programs like launchd, daemontools, and runit. Unlike some of these programs, it is not meant to be run as a substitute for init as “process id 1”. Instead it is ...
I am convinced that this issue is a packaging bug in the Supervisor package in Ubuntu 16.04 and it seems to have been caused by the switch to systemd: This issue was already reported upstream on the Supervisor project's issue tracker (where nothing can be fixed) in issue 735. I was bitten by this issue a few days ago and was astonished to find that this ...
Solution I inferred from a previous version of the documentation: /etc/supervisor/conf.d/spark_master.conf: command=/opt/spark-1.4.1/bin/spark-class org.apache.spark.deploy.master.Master directory=/opt/spark-1.4.1 /etc/supervisor/conf.d/spark_worker.conf: command=/opt/spark-1.4.1/bin/spark-class org.apache.spark.deploy.worker.Worker spark://spark-master:...
this was my problem, not sure if it helps. Aparently "service supervisord start" doesn't necessarily load your config file, or even a config file at all. In order to make mine work, I had to do a supervisord -c /path/to/my/config.conf (i.e. run the binary directly) this fixed everything. Hope this helps someone who runs into this.
OMG, I just now realize that this may be because of the environment: Vagrant. So, I remove my custom supervisor conf file which is calling a program in vagrant mounted filesystem. reboot and boom! it works! and the Vagrant solution is config.vm.provision "shell", inline: "service supervisor restart", run: "always"
cron by default running in a minimal environment, from man 5 cron: Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. PATH is set to "/usr/bin:/bin". HOME, SHELL, and PATH may be overridden by settings in ...
The autorestart directive specifies if supervisord should automatically restart a process if it exits when it is in the RUNNING state. (Source: http://supervisord.org/configuration.html) In other words, once the PHP page is processed...the interpreter exits...and the whole thing restarts again...and again...etc. Is that to be expected?
Use exec to replace bash with java: [program:programname] command=bash -c "source /path/to/env/file && exec java -jar /path/to/jar.jar" In such a case you will have only one process to be killed.
Make the command instead a shell script that replaces itself with the java? #!/bin/bash source /i/pity/da/env/foo exec java ...
What Munir mentioned is exactly how you do this. Basically you create a service file, and start it 30 times. Now that may seem a little unweildy, but it has advantages, such as being able to shut one of them down if it's misbehaving, and not have to shut all of them down. There are also some things you can do to make management easier. First, the unit file. ...
As pointed out by Mike Naberezny, here, all it needed was to add Type=forking to the Service section of the supervisord.service: [Service] Type=forking ExecStart=/usr/bin/supervisord ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown ExecReload=/usr/bin/supervisorctl $OPTIONS reload
I think you've mistaken the problem your programs have (or maybe didn't describe the question well enough) What supervisord is doing is creating a pipe for your program to write to (stdout and maybe stderr) and then supervisord is reading that pipe and writing to the log files. In other words, the program can never fail to write to stdout due to its own ...
AFAIK, supervisor does not support tidle ~ expansion, ~/config.json is treated as literal. You should change ~/config.json to its absolute path /path/to/config.json and make sure it can be accessed by nobody. More about supervisor configuration, see here.
Only top voted, non community-wiki answers of a minimum length are eligible