Files
projectsend/docker/production/supervisord.conf
ignacionelson 92a132d74f Give zip builds their own queue, so one archive cannot hold up the mail
The last piece of the #1687 follow-up. BuildZipDownloadJob allows itself
an hour, every shipped topology runs exactly one worker, and everything
shares the default queue -- so one large archive delayed every
notification email queued behind it. The size cap and the
one-build-per-person rule bounded that in July; they did not remove it.

onQueue('zips') in the constructor rather than at the dispatch site, so a
second caller cannot forget it. Both images grow a worker for it:
compose.yaml gains worker-zips, supervisord gains [program:queue-zips],
and the existing worker in each narrows to --queue=default. --tries=1
there matches the job, which records its own failure rather than being
retried.

The part that needs care is the manual install. A worker whose command
still says plain `queue:work` consumes `default` only, so it would send
email happily and never finish a single zip, with nothing in any log
saying why. INSTALL.md's unit now reads --queue=default,zips -- one
worker watching both, which is right for most installations -- and says
what happens if you leave it off, with the two-worker split offered for
anyone who would rather keep the two kinds of work apart. CHANGELOG
carries it as an upgrade note, since it is something to do rather than
something that was done.

Verified in the dev stack rather than only in a test: dispatched a build
and watched worker-zips take it while the default worker stayed idle.
2026-08-26 18:06:40 -03:00

75 lines
2.2 KiB
Plaintext

; Four processes, one container. The dev stack runs these as separate
; compose services; an official image people `docker run` has to carry them
; itself, or scheduled work and queued jobs silently never happen.
;
; Everything logs to stdout/stderr so `docker logs` is the single place to
; look — no log files inside the container to discover and rotate.
[supervisord]
nodaemon=true
user=root
logfile=/dev/null
logfile_maxbytes=0
pidfile=/run/supervisord.pid
[program:php-fpm]
command=php-fpm --nodaemonize
autostart=true
autorestart=true
priority=10
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
[program:nginx]
command=nginx -g "daemon off;"
autostart=true
autorestart=true
priority=20
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
; --max-time recycles the worker hourly. Long-lived PHP workers accumulate
; state, and a worker started before a deploy keeps running the old code
; until it exits; an hour bounds both without thrashing.
[program:queue]
command=su-exec www-data php /var/www/html/artisan queue:work --queue=default --max-time=3600 --tries=3
autostart=true
autorestart=true
priority=30
stopwaitsecs=3630
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
; Zip builds get their own worker. BuildZipDownloadJob allows itself an
; hour, and on the shared queue one large archive holds up every
; notification email queued behind it. --tries=1 matches the job, which
; records its own failure rather than being retried.
[program:queue-zips]
command=su-exec www-data php /var/www/html/artisan queue:work --queue=zips --max-time=3600 --tries=1
autostart=true
autorestart=true
priority=31
stopwaitsecs=3630
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
; schedule:work is the long-running equivalent of a per-minute cron entry,
; which is what a container should use — there is no crond here.
[program:scheduler]
command=su-exec www-data php /var/www/html/artisan schedule:work
autostart=true
autorestart=true
priority=40
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0