Today, we launch dovecot in the background and chasquid in the foreground using sudo. This means that dovecot failures won't propagate, and signals to the container (e.g. to stop it) also don't get propagated to dovecot (because it's in the background) or chasquid (because they don't go beyond the sudo process). Thanks to [Guiorgy@github](https://github.com/Guiorgy) for identifying the problem, proposing alternatives, help debugging, and discussing this in https://github.com/albertito/chasquid/pull/70.
64 lines
2.2 KiB
Plaintext
64 lines
2.2 KiB
Plaintext
|
|
# We launch two daemons inside the container: chasquid and dovecot.
|
|
# The supervisord program will act as init, and forward signals to them from
|
|
# outside the container, so shutdown/restarts/etc. is handled appropriately.
|
|
|
|
[supervisord]
|
|
user = root
|
|
# We run with --nodaemon (as per entrypoint.sh), that implicitly makes
|
|
# supervisord log to stdout _in addition_ to logfile.
|
|
# So set logfile to /dev/null to avoid duplicated entries.
|
|
logfile = /dev/null
|
|
logfile_maxbytes = 0
|
|
|
|
[program:dovecot]
|
|
command = /usr/sbin/dovecot -F -c /etc/dovecot/dovecot.conf
|
|
# TODO: confirm we don't need stopasgroup, or add it.
|
|
stdout_logfile = /dev/stdout
|
|
stdout_logfile_maxbytes = 0
|
|
stderr_logfile = /dev/stderr
|
|
stderr_logfile_maxbytes = 0
|
|
autorestart = false
|
|
priority = 201
|
|
|
|
[program:chasquid]
|
|
command = /usr/bin/chasquid
|
|
user = chasquid
|
|
group = chasquid
|
|
environment = USER="chasquid"
|
|
stdout_logfile = /dev/stdout
|
|
stdout_logfile_maxbytes = 0
|
|
stderr_logfile = /dev/stderr
|
|
stderr_logfile_maxbytes = 0
|
|
autorestart = false
|
|
# chasquid doesn't _need_ dovecot to start earlier, but it will emit a warning
|
|
# if dovecot auth it's not ready at startup. To minimize the chances of
|
|
# problems, have supervisord start it after dovecot. Still it's not guaranteed
|
|
# to be fully up by the time chasquid needs it (because it starts the
|
|
# components asynchronously), but it minimizes the problem.
|
|
priority = 202
|
|
|
|
|
|
# We intentionally don't auto-restart subprocesses on unexpected crashes, and
|
|
# make supervisord exit if that happens. That way, whatever error caused it is
|
|
# propagated to the container runner and the user can monitor and decide what
|
|
# to do.
|
|
[eventlistener:exit_on_process_fatal]
|
|
# fatal: when the starting attempts fail (e.g. bad configuration).
|
|
# exited: when it fails after starting up (e.g. random crash).
|
|
# stopped: when a user wants to stop the container (e.g. requests a restart,
|
|
# or a manual stop). We don't interfere with this one because it's
|
|
# intentionally targeting a specific process. If the user wanted to stop the
|
|
# whole container, they can.
|
|
events = PROCESS_STATE_FATAL, PROCESS_STATE_EXITED
|
|
priority = 100
|
|
command = /bin/bash -c '
|
|
while true; do
|
|
echo "READY";
|
|
read line;
|
|
kill -SIGTERM $PPID;
|
|
echo "RESULT 2";
|
|
echo -n "OK";
|
|
done;
|
|
'
|