supervision as supervisord does it: Postfix stopped, give-ups FATAL, reload's exit read

C-P42. postfix-script's start-fg runs master as its child and master
calls setsid() (Postfix 3.7.11, conf/postfix-script; src/master/master.c);
supervisord signals the pid alone (supervisor 4.2.5, process.py,
Subprocess.kill()). A stop of program postfix left master running - a
restart then found "already running" - and a container stop cut Postfix
off with SIGKILL. The wrapper now stays the parent of "postfix start-fg"
and on TERM/INT runs "postfix stop", asking again while start-fg is still
in its checks (master -t). stopwaitsecs=15.

C-V6. The wrapper's give-up on the milter sockets came after the default
startsecs, so it was EXITED and restarted for ever. startsecs is now
MILTER_WAIT_TIMEOUT + 10, exported by the entrypoint as POSTFIX_STARTSECS
and expanded by supervisord (options.py, processes_from_section(); a
non-number MILTER_WAIT_TIMEOUT stops the start): a give-up is "Exited too
quickly", BACKOFF, FATAL after startretries, crashexit. For those seconds
after each start the program is STARTING (the healthcheck's 90 s start
period covers it; the sender check counts no downtime then).

C-V5. logrotate had startsecs=0, so a refused config restarted it every
second for ever. startsecs=1: FATAL after startretries; crashexit reads
the event's processname and leaves logrotate's FATAL on Server > Health.

B-U2. "supervisorctl start" returns when a startsecs=0 program is RUNNING,
not when it ends, and mapped "already started" to success. The panel now
speaks supervisord's XML-RPC itself (internal/supervisor, RunOnce):
startProcess without waiting, getProcessInfo until it leaves
STARTING/RUNNING, exitstatus 0 or an error; a run in progress is waited
out and one of its own follows. A failed reload while program postfix is
not RUNNING is logged, not an error: the next master reads the files.
C-V10: postfix-reload rests EXITED after a run; the e2e process check
takes STOPPED or EXITED. C-P34: the dead "postfix set-permissions" branch
goes - postfix check's create-missing builds the queue tree.

Stand (2026-10-14, make e2e, exit 0; MILTER_WAIT_TIMEOUT=10 on the stand):
new supervision_stops_postfix_and_gives_up - supervisorctl restart postfix
writes postfix-script's "stopping the Postfix mail system" and leaves one
master; with the panel's sockets removed, start answers "postfix: ERROR
(spawn error)" (finish() sets spawnerr "Exited too quickly", onwait()
reads it first) and Postfix comes up once the panel is back; a
group-writable logrotate config ends FATAL with the container up; the
panel's Reload configuration answers only after mail.log has "refreshing
the Postfix mail system", postfix-reload EXITED. session_survives_restart
sees the stop line for the container's restart. Measured: master's own
"terminating on signal 15" never reaches mail.log (master TERMs its group,
postlogd included, before it logs). go vet and go test ./... pass on the
server (24 packages; new unit tests of RunOnce against a fake supervisord).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

build/supervisord.conf

@@ -8,9 +8,15 @@
 ; supervisord.py, runforever(), transitions every group in that order in one
 ; pass, with no wait for a program to be ready.)
 ;
-; If any managed process exhausts its restart retries (FATAL), the crashexit
-; event listener brings the whole container down so Docker's restart policy can
-; recreate it cleanly, rather than lingering with a dead component.
+; If a managed process of the mail path exhausts its restart retries (FATAL),
+; the crashexit event listener brings the whole container down so Docker's
+; restart policy starts it again (the same container: docs.docker.com, "Start
+; containers automatically", restart policies), rather than lingering with a
+; dead component. A program reaches FATAL only through BACKOFF, by exits that
+; come before its startsecs (supervisor 4.2.5, supervisor/process.py,
+; Subprocess.finish() and transition()): an exit after it is EXITED and simply
+; restarted, for ever. logrotate's FATAL is left on Server > Health
+; (build/crashexit.py).
 
 [supervisord]
 nodaemon=true
@@ -66,12 +72,22 @@ stdout_logfile_maxbytes=0
 stderr_logfile=/dev/stderr
 stderr_logfile_maxbytes=0
 
+; startsecs is MILTER_WAIT_TIMEOUT plus ten seconds (build/entrypoint.sh): the
+; wrapper's exit when the milter sockets never come counts as too quick, and
+; so does a Postfix that will not start. The price: for that long after each
+; start the program is STARTING, not RUNNING (supervisor 4.2.5,
+; supervisor/options.py, processes_from_section(): startsecs is expanded like
+; any value, %(ENV_x)s from supervisord's environment; assumptions C-V6).
+; stopwaitsecs covers "postfix stop", which waits five seconds for master
+; before it kills (build/postfix-wrapper.sh).
 [program:postfix]
 command=/usr/local/bin/postfix-wrapper.sh
 priority=300
 autostart=true
 autorestart=true
+startsecs=%(ENV_POSTFIX_STARTSECS)s
 startretries=3
+stopwaitsecs=15
 stdout_logfile=/dev/stdout
 stdout_logfile_maxbytes=0
 stderr_logfile=/dev/stderr
@@ -88,7 +104,9 @@ stderr_logfile_maxbytes=0
 ; crashexit listener. (start-fg: see build/postfix-wrapper.sh. supervisor
 ; 4.2.5, supervisor/process.py, Subprocess.finish(): with startsecs=0 no exit
 ; counts as "too quickly", so even a failed run ends EXITED - never BACKOFF,
-; never FATAL.)
+; never FATAL - with its exit status kept, which the panel reads
+; (internal/supervisor, RunOnce). Its resting state is STOPPED until the first
+; run, EXITED after it; assumptions C-V10.)
 [program:postfix-reload]
 command=/usr/sbin/postfix reload
 autostart=false
@@ -117,16 +135,21 @@ stdout_logfile_maxbytes=0
 stderr_logfile=/dev/stderr
 stderr_logfile_maxbytes=0
 
-; Periodic logrotate for /data/log/mail.log (daily, 7-14 files kept in the
-; image). Runs as root so logrotate can read/rotate the log. Exits non-zero when
-; the config is group/other-writable (logrotate would ignore it silently);
-; autorestart surfaces BACKOFF on the Status page.
+; Periodic logrotate for /data/log/mail.log (daily, 14 files kept). Runs as
+; root so logrotate can read/rotate the log. Exits non-zero at once when the
+; config is group/other-writable (logrotate would ignore it silently): with
+; startsecs=1 that exit is too quick; once startretries are spent the program
+; is FATAL, and Server > Health shows it. With startsecs=0 it was restarted
+; every second for ever, RUNNING and EXITED in turn (supervisor 4.2.5,
+; supervisor/process.py, Subprocess.finish(); assumptions C-V5). crashexit
+; leaves this FATAL alone: logrotate is not on the mail path.
 [program:logrotate]
 command=/usr/local/bin/logrotate-loop.sh
 priority=400
 autostart=true
 autorestart=true
-startsecs=0
+startsecs=1
+startretries=3
 stdout_logfile=/dev/stdout
 stdout_logfile_maxbytes=0
 stderr_logfile=/dev/stderr