Coprocesses are processes that run alongside the main application. Unlike tasks or other lifecycle hooks, coprocesses remain running. Coprocesses are treated as "secondary" to the main application. The
SIGUSR1 handlers for ContainerPilot don't forward these signals to the coprocess. The stdout/stderr of the coprocess is piped through the ContainerPilot logging system just as a
task does. Coprocesses will be restarted if the
restarts flag is set, but do not cause ContainerPilot to exit the way the main application does.
A coprocess accepts the following properties:
commandis the executable (and its arguments) that will run when the coprocess executes.
nameis a friendly name given to the coprocess for logging purposes - this has no effect on the coprocess execution. This value is optional, and defaults to the
commandif not given.
restartsis the number of times a coprocess will be restarted if it exits. Supports any non-negative numeric value (ex.
1) or the strings
"never". This value is optional and defaults to
Coprocesses are started immediately following the exit of the
preStart hook, before polling for
backend hooks, and before the main application starts. Because the coprocess may take some non-zero time to be "live" after it starts (for example, it needs to load its config from disk), if the main application depends on the coprocess to be running you'll need to account for this to avoid race conditions between the coprocess and the main application.
Because coprocess arguments are configured in the ContainerPilot configuration, you can use environment variables to templatize the configuration just as you would for other lifecycle hooks.
If ContainerPilot receives
SIGHUP it reloads its configuration as described in Signals and operations. All coprocesses are stopped when this happens. The restart limit for the coprocess is reset to the new
restarts value, even if was unchanged. And then the new coprocesses are started with the new configuration.