Serviços systemd

O Chinaski executa como serviços systemd padrão no Linux. Como são units de template, um único conjunto de arquivos executa qualquer número de sites no mesmo host. Esta página cobre as três famílias de units embarcadas: o próprio CMS, o backup diário e o adaptador opcional de assistente de IA: e como trabalhar com elas no dia a dia.

O serviço principal: `chinaski@<instance>`

Cada instância do CMS executa sob sua própria unit systemd. Habilite e inicie uma nova com o nome da instância:

systemctl enable --now chinaski@1

(2, prod, staging: qualquer coisa alfanumérica: funcionam da mesma forma.) Do que a unit cuida:

Executa o CMS como um usuário chinaski dedicado, sem login, a partir do diretório daquela instância.
Define os caminhos de banco de dados e saída automaticamente a partir do nome da instância: você normalmente não os configura.
Lê um arquivo de env por instância, /etc/chinaski<instance>/env, que você cria antes de iniciar. Ele deve conter CHINASKI_SECRET e LISTEN_URL (ligue ao loopback, por exemplo http://127.0.0.1:3001, quando um reverse proxy está à frente do site: os comentários do arquivo de exemplo explicam por que isso importa).
Reinicia em caso de falha com um pequeno atraso, limitado a cinco tentativas por minuto para que uma configuração quebrada não entre em loop infinito.
Para com um período de graça drenado (330 s) para requisições em voo; note que o limite próprio de wall-clock de um build em execução é 30 minutos, então um build no meio do shutdown é cancelado em vez de esperado: o site publicado não é afetado de qualquer forma.
Executa encaixotado: sistema de arquivos somente leitura, exceto seu próprio diretório, sem novos privilégios, /tmp privado, memória limitada a 1 GB, CPU a 200%.

Cada instância é a mesma unit com um nome diferente, e cada uma tem seu próprio banco de dados, saída e ambiente: veja Instances para o modelo completo.

Eventos e logs

Tudo vai para o journald, com a tag chinaski-<instance>:

journalctl -u chinaski@<instance>       # acompanhe com -f
systemctl status chinaski@<instance>

Se o serviço falhar ao iniciar, o journal mostra o porquê; o instalador aponta para lá automaticamente quando uma primeira inicialização falha.

O backup diário: `chinaski-backup@`

Cada instância recebe uma unit oneshot correspondente e um timer:

O serviço tira um snapshot do banco de dados da instância e espelha sua mídia: executando com uma visão somente leitura do diretório do site e acesso de escrita apenas ao diretório de backup.
O timer dispara diariamente às 03:17 no horário local (minuto deliberadamente ímpar para que múltiplas instâncias em um host não façam backup no mesmo instante), com um pequeno atraso aleatório, e se recupera se o host estava desligado quando era a hora.
Verifique se está registrado com systemctl list-timers chinaski-backup@<instance>.timer: após editar um agendamento, verifique, porque o systemd pula silenciosamente uma string de calendário com erro de digitação.
Limitado a rodar em menos de 10 minutos; mesmo um banco de 1 GB termina em bem menos de um minuto em disco local.

O adaptador opcional: `chinaski-mcp@`

Se você usa assistentes de IA contra a API de um site, esse adaptador tem sua própria unit por instância:

Ordenado após a unit do CMS da mesma instância (para que o CMS exista primeiro).
Lê sua URL de API e chave de API de /etc/chinaski<instance>/mcp-env (também com permissões travadas).
Envelope de recursos menor que o do CMS (metade da memória e da CPU), com o mesmo hardening de sandbox e reinício automático.

Habilite um com systemctl enable --now chinaski-mcp@<instance> depois que a instância do CMS correspondente existir.

Comandos do dia a dia

systemctl status chinaski@<instance>     # está rodando?
systemctl restart chinaski@<instance>    # após mudanças manuais de arquivos (ex.: assets de admin)
journalctl -u chinaski@<instance> -f     # acompanhe o log
systemctl list-timers 'chinaski-backup@*'   # confirme cada agendamento de backup

Os deploys não mudam a unit: o script de deploy cuida do reinício após um build verificado. Se mais tarde você adotar o Manager, ele comanda essas mesmas units pelo nome (start/stop/restart), para que instâncias possam passar para seu controle sem serem reinstaladas.

Proteções, em resumo

Reinício automático em caso de falha (com um teto de backoff contra loops de crash).
Paradas graciosas: requisições e builds se esvaziam antes do processo sair.
Tetos de memória/CPU por unit, ajustados para que um builder descontrolado não mate o host de fome.
Uma sandbox por instância: nenhuma instância pode ler ou escrever os arquivos de outra.
O journald captura tudo: nenhum daemon de logging separado para gerenciar.