Hypnotoad vs the systemd Deployment

The standard production path doesn’t use hypnotoad’s config file at all: the chinaski@<N> systemd unit launches cms.pl daemon -l ${LISTEN_URL} with workers/limits encoded in the unit itself.

What the systemd pattern bypasses vs running hypnotoad directly:

• Stop/restart/reload is systemd’s job: Restart=on-failure (with back-off, 5 attempts in a minute of failure then a hard stop), stop timeouts sized to let in-flight requests and build processes drain before shutdown (330 s grace on stop).
• Limits and hardening: memory caps, CPU quotas, task limits, and a filesystem sandbox come from the unit, not the server config.
• Per-instance env: every instance’s LISTEN_URL (must be loopback in production) and CHINASKI_SECRET come from /etc/chinaski<N>/env — a pattern that supports any number of instances from one unit file.

In exchange, the two features that make hypnotoad’s raw mode distinctive don’t apply: no zero-downtime USR2 reload (restart instead — a hard stop/start), and no bundled graceful-time config — the systemd unit’s stop policy covers it.

The contents of the env file are read by the unit at start (a missing file is non-fatal during initial setup, since the unit ships with a template EnvironmentFile=...). This is the production-standard mode; the direct-hypnotoad mode exists for offline/single-machine cases where systemd isn’t part of the picture.