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 ...
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.
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 ...
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 ...
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?
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 ...
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"
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