Hypnotoad vs a implantação systemd
O caminho padrão de produção não usa o arquivo de configuração do hypnotoad de forma nenhuma: a unit systemd chinaski@<N> lança o cms.pl daemon -l ${LISTEN_URL} com workers/limites codificados na própria unit.
O que o padrão systemd contorna vs executar o hypnotoad diretamente:
- Stop/restart/reload é trabalho do systemd: Restart=on-failure (com back-off, 5 tentativas em um minuto de falha e então uma parada rígida), timeouts de stop dimensionados para deixar requisições em voo e processos de build se esvaziarem antes do shutdown (330 s de graça no stop).
- Limites e hardening: tetos de memória, quotas de CPU, limites de tasks e uma sandbox de sistema de arquivos vêm da unit, não da configuração do servidor.
- Env por instância: o
LISTEN_URL(deve ser loopback em produção) e oCHINASKI_SECRETde cada instância vêm de/etc/chinaski<N>/env, um padrão que suporta qualquer número de instâncias a partir de um único arquivo de unit.
Em troca, as duas funcionalidades que tornam o modo bruto do hypnotoad distintivo não se aplicam: nenhum reload USR2 sem downtime (restart em vez disso, um stop/start rígido), e nenhuma configuração de graceful-time embarcada, a política de stop da unit systemd cobre isso.
O conteúdo do arquivo de env é lido pela unit ao iniciar (um arquivo ausente não é fatal durante a configuração inicial, já que a unit vem com um EnvironmentFile=... de template). Este é o modo padrão de produção; o modo hypnotoad-direto existe para os casos offline/máquina única onde o systemd não faz parte do quadro.