Giter VIP home page Giter VIP logo

supervisord's Introduction

Go Report Card

Why this project?

The python script supervisord is a powerful tool used by a lot of guys to manage the processes. I like supervisord too.

But this tool requires that the big python environment be installed in target system. In some situation, for example in the docker environment, the python is too big for us.

This project re-implements supervisord in go-lang. Compiled supervisord is very suitable for environments where python is not installed.

Building the supervisord

Before compiling the supervisord, make sure the go-lang 1.11+ is installed in your environment.

To compile supervisord for linux, run following commands:

  1. go generate
  2. GOOS=linux go build -tags release -a -ldflags "-linkmode external -extldflags -static" -o supervisord

Run the supervisord

After a supervisord binary has been generated, create a supervisord configuration file and start the supervisord like this:

$ cat supervisor.conf
[program:test]
command = /your/program args
$ supervisord -c supervisor.conf

Please note that config-file location autodetected in this order:

  1. $CWD/supervisord.conf
  2. $CWD/etc/supervisord.conf
  3. /etc/supervisord.conf
  4. /etc/supervisor/supervisord.conf (since Supervisor 3.3.0)
  5. ../etc/supervisord.conf (Relative to the executable)
  6. ../supervisord.conf (Relative to the executable)

Run as daemon with web-ui

Add the inet interface in your configuration:

[inet_http_server]
port=127.0.0.1:9001

then run

$ supervisord -c supervisor.conf -d

In order to manage the daemon, you can use supervisord ctl subcommand, available subcommands are: status, start, stop, shutdown, reload.

$ supervisord ctl status
$ supervisord ctl status program-1 program-2...
$ supervisord ctl status group:*
$ supervisord ctl stop program-1 program-2...
$ supervisord ctl stop group:*
$ supervisord ctl stop all
$ supervisord ctl start program-1 program-2...
$ supervisord ctl start group:*
$ supervisord ctl start all
$ supervisord ctl shutdown
$ supervisord ctl reload
$ supervisord ctl signal <signal_name> <process_name> <process_name> ...
$ supervisord ctl signal all
$ supervisord ctl pid <process_name>
$ supervisord ctl fg <process_name>

Please note that supervisor ctl subcommand works correctly only if http server is enabled in [inet_http_server], and serverurl correctly set. Unix domain socket is not currently supported for this pupose.

Serverurl parameter detected in the following order:

  • check if option -s or --serverurl is present, use this url
  • check if -c option is present, and the "serverurl" in "supervisorctl" section is present, use "serverurl" in section "supervisorctl"
  • check if "serverurl" in section "supervisorctl" is defined in autodetected supervisord.conf-file location and if it is - use found value
  • use http://localhost:9001

Check the version

Command "version" will show the current supervisord binary version.

$ supervisord version

Supported features

Http server

Http server can work via both unix domain socket and TCP. Basic auth is optional and supported too.

The unix domain socket setting is in the "unix_http_server" section. The TCP http server setting is in "inet_http_server" section.

If both "inet_http_server" and "unix_http_server" are not set up in the configuration file, no http server will be started.

Supervisord daemon settings

Following parameters configured in "supervisord" section:

  • logfile. Where to put log of supervisord itself.
  • logfile_maxbytes. Rotate log-file after it exceeds this length.
  • logfile_backups. Number of rotated log-files to preserve.
  • loglevel. Logging verbosity, can be trace, debug, info, warning, error, fatal and panic (according to documentation of module used for this feature). Defaults to info.
  • pidfile. Full path to file containing process id of current supervisord instance.
  • minfds. Reserve al least this amount of file descriptors on supervisord startup. (Rlimit nofiles).
  • minprocs. Reserve at least this amount of processes resource on supervisord startup. (Rlimit noproc).
  • identifier. Identifier of this supervisord instance. Required if there is more than one supervisord run on one machine in same namespace.

Supervised program settings

Supervised program settings configured in [program:programName] section and include these options:

  • command. Command to supervise. It can be given as full path to executable or can be calculated via PATH variable. Command line parameters also should be supplied in this string.
  • process_name. the process name
  • numprocs. number of process
  • numprocs_start. ??
  • autostart. Should be supervised command run on supervisord start? Defaults to true.
  • startsecs. The total number of seconds which the program needs to stay running after a startup to consider the start successful (moving the process from the STARTING state to the RUNNING state). Set to 0 to indicate that the program needn’t stay running for any particular amount of time.
  • startretries. The number of serial failure attempts that supervisord will allow when attempting to start the program before giving up and putting the process into an FATAL state. See Process States for explanation of the FATAL state.
  • autorestart. Automatically re-run supervised command if it dies.
  • exitcodes. The list of “expected” exit codes for this program used with autorestart. If the autorestart parameter is set to unexpected, and the process exits in any other way than as a result of a supervisor stop request, supervisord will restart the process if it exits with an exit code that is not defined in this list.
  • stopsignal. Signal to send to command to gracefully stop it. If more than one stopsignal is configured, when stoping the program, the supervisor will send the signals to the program one by one with interval "stopwaitsecs". If the program does not exit after all the signals sent to the program, supervisord will kill the program.
  • stopwaitsecs. Amount of time to wait before sending SIGKILL to supervised command to make it stop ungracefully.
  • stdout_logfile. Where STDOUT of supervised command should be redirected. (Particular values described lower in this file).
  • stdout_logfile_maxbytes. Log size after exceed which log will be rotated.
  • stdout_logfile_backups. Number of rotated log-files to preserve.
  • redirect_stderr. Should STDERR be redirected to STDOUT.
  • stderr_logfile. Where STDERR of supervised command should be redirected. (Particular values described lower in this file).
  • stderr_logfile_maxbytes. Log size after exceed which log will be rotated.
  • stderr_logfile_backups. Number of rotated log-files to preserve.
  • environment. List of VARIABLE=value to be passed to supervised program. It has higher priority than envFiles.
  • envFiles. List of .env files to be loaded and passed to supervised program.
  • priority. The relative priority of the program in the start and shutdown ordering
  • user. Sudo to this USER or USER:GROUP right before exec supervised command.
  • directory. Jump to this path and exec supervised command there.
  • stopasgroup. Also stop this program when stopping group of programs where this program is listed.
  • killasgroup. Also kill this program when stopping group of programs where this program is listed.
  • restartpause. Wait (at least) this amount of seconds after stpping suprevised program before strt it again.
  • restart_when_binary_changed. Boolean value (false or true) to control if the supervised command should be restarted when its executable binary changes. Defaults to false.
  • restart_cmd_when_binary_changed. The command to restart the program if the program binary itself is changed.
  • restart_signal_when_binary_changed. The signal sent to the program for restarting if the program binary is changed.
  • restart_directory_monitor. Path to be monitored for restarting purpose.
  • restart_file_pattern. If a file changes under restart_directory_monitor and filename matches this pattern, the supervised command will be restarted.
  • restart_cmd_when_file_changed. The command to restart the program if any monitored files under restart_directory_monitor with pattern restart_file_pattern are changed.
  • restart_signal_when_file_changed. The signal will be sent to the proram, such as Nginx, for restarting if any monitored files under restart_directory_monitor with pattern restart_file_pattern are changed.
  • depends_on. Define supervised command start dependency. If program A depends on program B, C, the program B, C will be started before program A. Example:
[program:A]
depends_on = B, C

[program:B]
...
[program:C]
...

Set default parameters for all supervised programs

All common parameters that are identical for all supervised programs can be defined once in "program-default" section and omitted in all other program sections.

In example below the VAR1 and VAR2 environment variables apply to both test1 and test2 supervised programs:

[program-default]
environment=VAR1="value1",VAR2="value2"
envFiles=global.env,prod.env

[program:test1]
...

[program:test2]
...

Group

Section "group" is supported and you can set "programs" item

Events

Supervisord 3.x defined events are supported partially. Now it supports following events:

  • all process state related events
  • process communication event
  • remote communication event
  • tick related events
  • process log related events

Logs

Supervisord can redirect stdout and stderr ( fields stdout_logfile, stderr_logfile ) of supervised programs to:

  • /dev/null. Ignore the log - send it to /dev/null.
  • /dev/stdout. Write log to STDOUT.
  • /dev/stderr. Write log to STDERR.
  • syslog. Send the log to local syslog service.
  • syslog @[protocol:]host[:port]. Send log events to remote syslog server. Protocol must be "tcp" or "udp", if missing, "udp" assumed. If port is missing, for "udp" protocol, it's defaults to 514 and for "tcp" protocol, it's value is 6514.
  • file name. Write log to specified file.

Multiple log files can be configured for the stdout_logfile and stderr_logfile with ',' as delimiter. For example:

stdout_logfile = test.log, /dev/stdout

syslog settings

if write the log to the syslog, following additional parameter can be set like:

syslog_facility=local0
syslog_tag=test
syslog_stdout_priority=info
syslog_stderr_priority=err
  • syslog_facility, can be one of(case insensitive): KERNEL, USER, MAIL, DAEMON, AUTH, SYSLOG, LPR, NEWS, UUCP, CRON, AUTHPRIV, FTP, LOCAL0~LOCAL7
  • syslog_stdout_priority, can be one of(case insensitive): EMERG, ALERT, CRIT, ERR, WARN, NOTICE, INFO, DEBUG
  • syslog_stderr_priority, can be one of(case insensitive): EMERG, ALERT, CRIT, ERR, WARN, NOTICE, INFO, DEBUG

Web GUI

Supervisord has builtin web GUI: you can start, stop & check the status of program from the GUI. Following picture shows the default web GUI:

alt text

Please note that in order to see|use Web GUI you should configure it in /etc/supervisord.conf both in [inet_http_server] (and|or [unix_http_server] if you prefer unix domain socket) and [supervisorctl]:

[inet_http_server]
port=127.0.0.1:9001
;username=test1
;password=thepassword

[supervisorctl]
serverurl=http://127.0.0.1:9001

Usage from a Docker container

supervisord is compiled inside a Docker image to be used directly inside another image, from the Docker Hub version.

FROM debian:latest
COPY --from=ochinchina/supervisord:latest /usr/local/bin/supervisord /usr/local/bin/supervisord
CMD ["/usr/local/bin/supervisord"]

Integrate with Prometheus

The Prometheus node exporter supported supervisord metrics are now integrated into the supervisor. So there is no need to deploy an extra node_exporter to collect the supervisord metrics. To collect the metrics, the port parameter in section "inet_http_server" must be configured and the metrics server is started on the path /metrics of the supervisor http server.

For example, if the port parameter in "inet_http_server" is "127.0.0.1:9001" and then the metrics server should be accessed in url "http://127.0.0.1:9001/metrics"

Register service

Autostart supervisord after os started. Look up supported platforms at kardianos/service.

# install
sudo supervisord service install -c full_path_to_conf_file
# uninstall
sudo supervisord service uninstall
# start
supervisord service start
# stop
supervisord service stop

supervisord's People

Contributors

akkuman avatar al2klimov avatar alexstocks avatar andrewbasterfield avatar andrewhsu avatar bingoohuang avatar blinkinglight avatar cxjava avatar czerasz avatar dependabot[bot] avatar eastonlee avatar eleksir avatar foobar2016 avatar joshdvir avatar kemadz avatar kmfukuyama avatar kuri-su avatar lsl avatar n-rodriguez avatar ochinchina avatar opriz avatar prashanthjbabu avatar radutopala avatar rbeuque74 avatar rev1si0n avatar ruudk avatar shidaxi avatar siecje avatar vvarp avatar zl21st avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

supervisord's Issues

Syslog daemon and named pipes

Currently i'm writing a go-syslogd to get following features:

  • syslog handling of /dev/log
  • creation of named pipes to provide applications a possibility to write to a "logfile" which instead writes to a daemon instead into a file (some daemons have splitted master and childrens)

Would be nice to have this solution in a supervisord (like systemd). At the moment we're using the original supervisord.

Are you planing to implement something like that? Would be easy in golang and maybe i can help if you want this feature implemented in your supervisord.

"supervisord ctl" not support unix socket

if the serverurl is a unix socket like "unix:///var/run/supervisor.sock", we get error like:

Fail to send request to supervisord: Post unix:///var/run/supervisor.sock/RPC2: unsupported protocol scheme "unix"

can divided into several packages for import

Right now, there is only a folder, and all files are in main package.

In my programme, I want to import xmlrpc-client for xmlrpc call, so would you divide the main package into several packages for importing?

Current importing returns:

import "github.com/ochinchina/supervisord" is a program, not an importable package

config to achieve continous restart if failed

I have an app which should be monitored and always restarted in case of exit or failure (also if it keeps exiting). What I want to avoid is supervisord to stop restarting the app after some retries, but I doesnt work...
This is the tail of the output of supervisord:

time="2017-07-02T10:58:50Z" level=info msg="Don't start the stopped program because its retry times 3 is greater than start retries 3" program=recorder


supervisord.conf:

[program:recorder]
command=/usr/sbin/recorder
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/recorder.log

With this config the superviord still stops trying after some cycles. Why?

eventlistener processes are never started

In the getAllProcess method of ProcessManager only the procs field is iterated over:

for _, proc := range pm.procs {
tmpProcs = append(tmpProcs, proc)
}

Processes created from eventlistener sections are added to the eventListeners field. As a result, the event listener processes are not started in StartAutoStartPrograms...

pm.ForEachProcess(func(proc *Process) {
if proc.isAutoStart() {
proc.Start(false)
}
})

...and the registerEventListener method is never called:

events := strings.Split(p.config.GetString("events", ""), ",")
for i, event := range events {
events[i] = strings.TrimSpace(event)
}
p.registerEventListener(p.config.GetEventListenerName(),
events,
in,
out)

Perhaps the solution is to iterate over both process maps in the manager:

func (pm *ProcessManager) getAllProcess() []*Process {
	tmpProcs := make([]*Process, 0)
	for _, proc := range pm.procs {
		tmpProcs = append(tmpProcs, proc)
	}
	for _, eventListener := range pm.eventListeners {
		tmpProcs = append(tmpProcs, eventListener)
	}
	return sortProcess(tmpProcs)
}

Better error reporting

If you run a script that is not executable it will not start but you don't get a good error message.

From docker

COPY --from=ochinchina/supervisord:latest /usr/local/bin/supervisord /usr/local/bin/supervisord
Error response from daemon: pull access denied for ochinchina/supervisord, repository does not exist

https://hub.docker.com/ochinchina/supervisord 404, plz fix it if you can

Program Dependancies

I know your goal is to replicate the features of supervisord in go...

I was wondering what your take would be on adding a couple that aren't in supervisord?

Or perhaps restructuring the project so the core can be used as a library by other projects to implement the wanted features? (I'd be willing to do this as the alternative is to fork it entirely)

I really want to be able to record program dependancies.

Choose a different name to avoid confusion

Please choose another name for this project. The name supervisord is already used by similar project since 2004. By giving this project the exact same name, it creates confusion.

This will be especially true if a system ends up having both the Python package installed and this one. The user may not realize which program is run.

support for environment variables in configuration options

Hello. Thank you for your project. I'm using go-supervisord for my docker container and it's really cool. I'm having a small feature request: i would like to use environment variables inside configuration options. I think i can create a PR but i would like to know your opinion about this feature first.

Add running as group

In addition to running as a specific user, you should be able to specify a specific Linux group.

2 verisons exist: 1.0.005 and 3.0

Now there are 2 versions defined, one is 1.0.005 in version.go which got by supervisord version, the other one is 3.0 in supervisor.go which got by xmlrpc.

Can these 2 verisons merge into one?

Add Docker Hub automated build for supervisord

May I suggest the addition of a Dockerfile and configuration of an automated build on Docker Hub. That way those wishing to add supervisord to a Docker image could simply do:

COPY --from=ochinchina/supervisord:latest /usr/local/bin/supervisord /usr/local/bin/supervisord

Perhaps something along the lines of:

FROM golang:latest

ADD . /go/src/github.com/ochinchina/supervisord
RUN go build -o /usr/local/bin/supervisord github.com/ochinchina/supervisord

ENTRYPOINT ["supervisord"]

Once Docker Hub supports multi-stage builds more space efficient and Alpine based build could be added.

version 命令未注册

(supervisor3.0版本)

supervisord此处为xmlrpc远程调用,从抓包来看,supervisor内部的version命令,实际上调用了两个函数,因此需要增加注册:

        xmlrpcCodec.RegisterAlias( "supervisor.getSupervisorVersion", "Supervisor.GetVersion" )//此行新增
        xmlrpcCodec.RegisterAlias( "supervisor.getVersion", "Supervisor.GetVersion" )//此行为原来的

numprocs issue

I've added numprocs=2, but it didn't started two processes for that program. Any ideas?

stopwaitsecs没效果?

stopwaitsecs时间后程序没结束不发送kill强制终止?
配置:
[supervisord]
logfile=/var/log/supervisord.log
logfile_maxbytes=50MB
logfile_backups=10
loglevel=debug
pidfile=/tmp/supervisord.pid

[inet_http_server]
port=127.0.0.1:9001

[program:test]
command=/root/test
autostart=true
autorestart=true
startsecs=2
startretries=3
stopwaitsecs=5
stopsignal=INT
stdout_logfile=/root/stdout.log
stdout_logfile_maxbytes=1MB
stdout_logfile_backups=10
redirect_stderr=true

Uptime value error

supervisor> status
test RUNNING pid 29897, uptime 02:142:8531

expected value:
uptime 02:22:11

reload does not stop the removed program

If I remove one program from the supervisord.conf and reload, the removed program can still be got by supervisord ctl status, and the program is still running.

I think the removed program should be stopped and removed from the management of supervisord ctl status.

environment file support needed

Currently, to pass an environment variable to supervisord process we need to "export ENV_NAME=value". This will cause inconvenience sometime and also will be required to set a lot of environment variables.

We want to put all the related environment variables to a single file and the supervisor load this environment file and set it for the program.

zombie alert!

We're running a kubernetes docker container environment and use this go supervisord (as the pid 1 master) to spawn processes. It works well, but when certain processes are terminated/killed, there are zombies left. I'm not an expert on this, but my feeling is that this supervisord isn't properly handling certain system signal events and hence a final cleanup step isn't happening.

e.g. running tmux and exiting via ctrl-d gives this (truncated) process listing

$ ps aux
user           1  0.0  0.0 362736  6052 ?        Ssl  22:56   0:00 /cocalc/bin/supervisord -c /cocalc/supervisor/supervisord.conf
[...]
user         114  0.2  0.0      0     0 ?        Zs   22:56   0:01 [tmux] <defunct>
user         115  0.0  0.0      0     0 ?        Zs   22:56   0:00 [bash] <defunct>

has anyone else experienced this?

version: 1.0.006

nginx won't start.

I'm trying to run nginx but it keeps looping on wait program exit and success to start program.

This works with the Python supervisord.

# /boot/tp/bin/supervisord -c /boot/app/sysfiles/supervisord/nginx.conf 
INFO[0000] create process:nginx                         
INFO[0000] try to start program                          program=nginx
INFO[0000] success to start program                      program=nginx
DEBU[0001] wait program exit                             program=nginx
INFO[0001] success to start program                      program=nginx
DEBU[0002] wait program exit                             program=nginx
INFO[0002] success to start program                      program=nginx
DEBU[0003] wait program exit                             program=nginx
INFO[0003] success to start program                      program=nginx
DEBU[0004] wait program exit                             program=nginx
INFO[0004] success to start program                      program=nginx
DEBU[0005] wait program exit                             program=nginx
INFO[0005] success to start program                      program=nginx
^CINFO[0005] receive a signal to stop all process & exit   signal=interrupt
DEBU[0006] wait program exit                             program=nginx
INFO[0006] stop the program                              program=nginx

Here is the nginx config.

[program:nginx]
# See /boot/tp/nginx/nginx.conf
command=/boot/tp/nginx/sbin/nginx -g "daemon off;"
autostart=true
autorestart=true
stdout_logfile=syslog
stderr_logfile=syslog
user=nginx

Run as daemon

Is there a way to run as a daemon?

Seems like the child processes do not see the exit signal from the supervisor parent. If I kill the supervisor via kill -9, the child processes continue to exist.

Custom stop logic

Is it possible to have custom logic run instead of the default behaviour when supervisord ctl stop $program is called?

Maybe add a config value which can be set to a script and that script is run when stop is called?

supervisord ctl -c option not working for second supervisord

I have two supervisord running, using 9001 and 9002 ports respectively. I use the following command to access supervisorctl for the second one

supervisord ctl -c supervisor_9002.conf status

But it goes to default server at 9001. My conf file has the section for supervisorctl:

[inet_http_server]
port=127.0.0.1:9002
[supervisorctl]
serverurl=http://127.0.0.1:9002

Although using -s option works:
supervisord ctl -s http://localhost:9092 status

Why doesn't -c option work as desired? Or am I missing something?

Number of child processes

I have an issue with numprocs.

If I try to launch more than 200 instances (eg. 201) of the same command at once, it stalls and the ctl status does not return anything anymore. But it works well with <=200 instances.

The same trial with the Py supervisor works fine, I can launch for example 1000 instances of the same command.

eventlistener uses 100% CPU while listening

When an eventlistener is added supervisord uses 100% CPU even if all programs are idle. Take for example:

[program:a]
command = bash -c "sleep 8 && exit 2"

[eventlistener:a_exit]
command = ./event.sh
events=PROCESS_STATE_EXITED,PROCESS_STATE_FATAL

where event.sh is:

#!/bin/sh
echo READY
read header
pkill supervisord

You should see this using 100% CPU for 8 seconds before it exits. Removing the eventlistener section solves the CPU issue, but supervisord doesn't exit.

Error when compiling for ARM

While compiling from ARM I get following output:

user@ubuntu:~/supervisord-0.1$ GOOS=linux GOARCH=arm go build supervisor.go
# command-line-arguments
./supervisor.go:19: undefined: Config
./supervisor.go:20: undefined: ProcessManager
./supervisor.go:21: undefined: XmlRPC
./supervisor.go:22: undefined: Logger

Simple hello example doesn't seem to work

Not sure what I'm doing wrong.

$ ls -l hello*
-rw-rw-r--. 1 jjones jjones 94 Jun  8 11:01 hello.conf
-rwxrwxr-x. 1 jjones jjones 64 Jun  8 10:58 hello.sh
$ cat hello.sh
#!/usr/bin/env bash

while :
do
    echo hello
    sleep 1
done
$ cat hello.conf
[program:hello]
stdout_logfile = /dev/stdout
stdout_logfile_maxbytes = 0
command = ./hello.sh
$ supervisord -c hello.conf
INFO[0000] try to start program                          program=hello
INFO[0000] create process:hello
INFO[0000] success to start program                      program=hello
DEBU[0000] wait program exit                             program=hello
INFO[0001] success to start program                      program=hello
DEBU[0001] wait program exit                             program=hello
INFO[0002] success to start program                      program=hello
DEBU[0002] wait program exit                             program=hello
INFO[0003] success to start program                      program=hello
DEBU[0003] wait program exit                             program=hello
INFO[0004] success to start program                      program=hello
DEBU[0004] wait program exit                             program=hello

supervisord ctl stop doesn't work for inner commands

In my supervisord config I'm running a script which sets some environment variables and then runs a script. If I do supervisord ctl stop $program it removes the first script but re-parents the inside script to be a child of init and continues to run. After supervisord ctl stop, it still shows as running in supervisord status and is actually still running.

Here are the test files I am using.

supervisord config

[inet_http_server]
port=127.0.0.1:9001

[program:one]
command=/home/siecje/Desktop/one.sh

one.sh

#!/bin/sh

/home/siecje/.virtualenvs/edms/bin/python /home/siecje/Desktop/one.py

one.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    import waitress
    waitress.serve(app, host = "localhost", port = 5000)

one.py will run forever serving a web application. In order to run it you will need to pip install Flask waitress.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.