Skip to content

v2.0.8 — eliminate first-boot crash-loop on slow hosts

Choose a tag to compare

@ibnbd ibnbd released this 10 May 11:00
· 284 commits to main since this release

What this fixes

Some operators on slower / entropy-starved VPS hosts saw the container
go into a crash-loop on a fresh deploy:

[init-mailcue] Starting initialisation for domain=...
[init-mailcue] Generating TLS certificates (CA + server)...
s6-rc: fatal: timed out
s6-sudoc: fatal: unable to get exit status from server: Operation timed out

The init oneshot was synchronously generating a 4096-bit CA + a 2048-bit server cert + a 2048-bit DKIM key, plus running alembic migrations, all under a 30-second S6_CMD_WAIT_FOR_SERVICES_MAXTIME. On a constrained host the cert step alone could hit 30s and s6-rc would kill the script before it finished.

Changes

  • S6_CMD_WAIT_FOR_SERVICES_MAXTIME 30 000 ms → 300 000 ms (5 min). Smallest ceiling that's safe on a slow VPS without disabling the timeout entirely.
  • Persist /etc/ssl/mailcue as a named volume in docker-compose.deploy.yml and docker-compose.production.yml. Previously this directory lived in the container's writable layer, so every image upgrade discarded the certs, re-ran the slow generation path, and rotated the self-signed CA fingerprint that any client had pinned. With the volume, cert generation is a one-time cost.

Hot-patch for existing deployments

If you're hitting the crash-loop and don't want to wait for the new image:

environment:
  - S6_CMD_WAIT_FOR_SERVICES_MAXTIME=300000

then docker compose up -d. Re-pull 2.0.8 afterwards to pick up the volume change.

Known follow-up (not in this release)

Postfix and Dovecot still read /etc/ssl/mailcue/server.crt regardless of MAILCUE_TLS_CERT_PATH or MAILCUE_ACME_EMAIL — only Nginx picks up the Let's Encrypt / custom cert. Email clients validating SMTP/IMAP TLS will see the self-signed CA until the production-mode init is taught to symlink the trusted cert into server.crt/server.key as well.

Full Changelog: v2.0.7...v2.0.8