-Here is an example of a config file with
all the supported
+Here is an example of a config file with supported
command = /usr/bin/run-my-server.sh
+ MY_DB_URI = postgres://localhost:9987
The 'my-app' section provides the command to run the application. It
will be provided a HOST and PORT via environment variables (env
- export $MY_DB_URI=postgres://localhost:9987
- python -m mywebapp.run -h $HOST -p $PORT
+ python -m mywebapp.run -h $HOST -p $PORT --dburi=$MY_DB_URI
-In this scenario we've passed the host
and port as command line
+In this scenario we've passed the host as command line
arguments but a better design is to look for the HOST and PORT from
the environment variables.
The "PWD" path is provided by default and is the sandbox
directory. Also, you can see that we provided our own "PORT" env
-var. This will override
a port provided by the system.
+var. This will override port provided by the system.
-NOTE: By providing a "PORT" env var, you restrict that app to only one
-instance. This is necessary in order to avoid collisions.
+NOTE: By providing a "PORT" env var, you are responsible for dealing
+with any conflicts between processes.
Interacting with Processes
-The start of the application is the running of the command in a
-directory dedicated to the application. The directoy MAY be used for
-writing temporary files but those file will be removed upon a stop or
-restart of the process. In order to keep the same directory and still
-restart the process a "graceful" restart can be requested in which
-case it will use the same the environment. If for some reason the
-graceful restart fails, the fallback is the same as a typical
+The start of the application is when the main command is run in the
+application's sandbox directory.
The start command can be provided configuration information in its
initial config. Any key/value pair will be added as env vars. For
it to exit and then running the start command again. You can also
specify when restarting some parameters.
-A hard restart is when after issuing the SIGTERM to the process it
-does not stop on its own. The default means of identifying this
-situation is a simple timeout. Some other scenarios can be
-configured such as waiting for a file handle to change or accessing a
-known URL for a certain response.
-Here is how to configure a check before issuing a SIGKILL. ::
- restart_test = verify-foo-shutdown
-The 'restart_test' configuration parameter defines a process to run
-that will perform any tests to ensure the process is stopped
-safely. In the case where both processes are not responding, sending a
-stop command with a SIGKILL will kill both the initial process and its
-A graceful restart acts just like a normal restart with the single
-difference being that the same working directory is guaranteed to
-exist when the application comes back up.
good example would be running a test suite or performing a data
migration/clean up script.
-These commands are run in the same working directory as the
-application using the same permissions and env vars.
+These commands must be available in the same way the start command is
+available. They are run in the same sandbox directory and uses the
+same permissions and env vars.
Here is an example of configuring a custom interaction point. ::