Nosso watchdog reiniciou os serviços que havíamos parado de propósito

Operações2026-10-31

Um de nossos watchdogs inicia qualquer serviço nosso que esteja habilitado, mas não em execução. Duas vezes em outubro, ele iniciou serviços que havíamos parado de propósito. Na segunda vez, visitantes de um de nossos sites receberam erros por cerca de 45 minutos.

Por que esse watchdog existe

Um serviço que sai limpo ao receber SIGTERM, por exemplo porque algo o matou pelo nome, não é considerado "failed" pelo systemd. Restart=on-failure não o traz de volta, e systemctl --failed não o lista. Ele permanece parado até que alguém perceba. Então o watchdog procura serviços que estão habilitados, mas não em execução, e os inicia.

O problema é que um serviço que você parou manualmente parece exatamente igual.

A primeira vez

Em 7 de outubro, paramos um worker de vídeo com systemctl stop às 12:47 para editar sua fila de tarefas. Às 12:55, ele estava rodando novamente: o watchdog o havia iniciado.

A segunda vez

Em 21 de outubro, precisávamos da memória da máquina que também serve dois de nossos sites para um teste de modelo. Um script parou as web apps dos sites, um job de sincronização e um container de banco de dados, novamente com systemctl stop. Cerca de cinco minutos depois, um timer que monitora os sites e, às 19:14, o watchdog, trouxeram o túnel e as web apps de volta.

O túnel voltou a receber tráfego, mas as web apps não conseguiam responder: o modelo em teste ocupava 114 GiB da memória da máquina. De aproximadamente 19:14 às 20:00, alguns visitantes receberam erros 502. Às 20:00, desabilitamos o túnel, as web apps e o job de sincronização, e paramos o timer de monitoramento.

A regra que usamos agora

• Pausar um serviço desabilitando-o: sudo systemctl disable --now <unit>. Traga-o de volta com sudo systemctl enable --now <unit>. Nosso watchdog só olha para serviços habilitados, então um desabilitado é deixado em paz.
• Pause tudo que possa trazê-lo de volta: o túnel na frente dele e qualquer timer que o monitore.
• Uma parada curta é uma corrida. Se você usar apenas stop, termine antes da próxima verificação, que em nossas máquinas ocorre em questão de minutos.

Mais duas armadilhas do systemd dos mesmos meses

• systemctl mask --runtime não faz nada para um arquivo de unidade em /etc/systemd/system. As unidades em /etc têm prioridade sobre a máscara de runtime em /run, então o comando é bem-sucedido e o serviço ainda inicia. Para segurar um serviço, usamos um drop-in com ConditionPathExists=!/etc/<name>.hold: enquanto esse arquivo existir, o serviço não iniciará, nem na inicialização nem manualmente.
• systemctl is-active chama um serviço oneshot em execução de inativo. Enquanto um serviço Type=oneshot está em execução, seu estado é "activating", então is-active imprime isso e retorna 3. Um loop como while systemctl is-active --quiet job.service; do sleep 60; done, feito para esperar por um trabalho noturno, sai imediatamente. Leia o estado em vez disso: active, activating, reloading ou deactivating significam todos que ele ainda está em andamento.

Factory Floor observa serviços habilitados que não estão em execução. Por padrão, ele apenas os reporta e os inicia apenas se você ativar essa opção. Desde a versão 1.0.3, seu alerta também diz como pausar um serviço propositalmente, e seu runbook diz o mesmo.