Anatomia de um SIGKILL no login failure daemon: depurando a falha de inicialização do LFD no Linux

Se você administra um servidor Linux com cPanel e ConfigServer Security & Firewall (CSF), já deve ter passado por aquele momento em que tenta iniciar o serviço do Login Failure Daemon (LFD) e o systemd devolve um erro intimidador: status=9/KILL.

Ver um daemon cair com sinal 9 imediatamente após o comando de start assusta, porque o SIGKILL normalmente indica que o kernel ou um processo externo encerrou a execução sem permitir qualquer rotina de limpeza. Para piorar a confusão, ao tentar rodar scripts de teste do firewall, é muito fácil se perder em mensagens de erro sobre módulos ausentes do Perl.

Passei por esse cenário recentemente em um ambiente com AlmaLinux e cPanel. Abaixo, mostro o que realmente causa esse sinal 9, por que o erro do Perl não era o verdadeiro vilão e como colocar o serviço de pé de forma limpa.

O sintoma e o susto do status 9/KILL#

Ao checar o status do serviço pelo systemd logo após a falha:

systemctl status lfd.service

O terminal exibia algo parecido com isto:

● lfd.service - ConfigServer Firewall & Security - lfd
     Loaded: loaded (/usr/lib/systemd/system/lfd.service; enabled; vendor preset: disabled)
     Active: failed (Result: signal) since Mon 2026-09-14 02:20:11 -03; 4s ago
    Process: 14820 ExecStart=/usr/sbin/lfd (code=killed, signal=KILL)
   Main PID: 14820 (code=killed, signal=KILL)
     Status: "Starting lfd..."

Diferente do SIGTERM (sinal 15), que é um pedido educado para que o processo feche arquivos abertos e termine suas rotinas com calma, o SIGKILL (sinal 9) é impiedoso:

1. O escalonador do kernel remove o processo da fila de execução na mesma hora.
2. A memória alocada é liberada imediatamente.
3. Nenhuma rotina de encerramento (como remover arquivos .pid residuais) consegue rodar.

Quando um serviço falha dessa forma durante o boot, a primeira suspeita costuma recair sobre o OOM Killer (falta de memória RAM) ou um encerramento forçado pelo wrapper do próprio firewall.

A pista falsa do cpstrict.pm no perl#

Tentando entender a falha, o primeiro reflexo foi rodar o script nativo de verificação do CSF:

perl /usr/local/csf/bin/csftest.pl

O resultado foi uma mensagem de erro direta na tela:

Can't locate cPstrict.pm in @INC (you may need to install the cPstrict module) (@INC contains: /usr/local/cpanel /usr/local/lib64/perl5 ...) at /usr/local/csf/bin/csftest.pl line 14.
BEGIN failed--compilation aborted at /usr/local/csf/bin/csftest.pl line 14.

No ecossistema Perl, a variável global @INC guarda os caminhos de pastas onde o interpretador busca módulos (.pm). Em servidores com cPanel, módulos internos como cPstrict.pm residem dentro de caminhos próprios em /usr/local/cpanel/.

Ao chamar o script pelo interpretador /usr/bin/perl do sistema sem carregar as variáveis de ambiente completas do cPanel, o Perl reclamou do módulo faltante. Isso parecia uma quebra grave de dependências, mas era apenas uma pista falsa provocada pela forma como o comando de teste foi executado. O problema do lfd tinha outra origem.

A causa real: o freio de mão do modo TESTING#

A resposta real não estava nas mensagens genéricas do systemd nem no erro do Perl. Ela estava registrada no arquivo de log da própria aplicação:

cat /var/log/lfd.log | tail -n 20

E lá estava o motivo do encerramento:

*Error* lfd will not run with TESTING enabled in /etc/csf/csf.conf, at line 112
daemon stopped

O CSF vem por padrão com a diretiva TESTING = "1" ativada. Esse modo de teste é uma trava de segurança intencional: ele aplica as regras no firewall, mas roda um cron temporário que limpa as tabelas a cada poucos minutos para evitar que você fique trancado fora do próprio servidor por um erro de digitação nas portas.

O lfd, por sua vez, é o daemon ativo que monitora logs de autenticação e bloqueia IPs em tempo real. Se o modo de teste estiver ativado, o script em Perl simplesmente executa a função die() logo após carregar as configurações. O wrapper do CSF encerra a rotina e o systemd registra o encerramento abrupto com o sinal de morte do processo.

Outras hipóteses que valem descartar em casos de SIGKILL#

Antes de concluir que o erro sempre será o modo de teste, existem dois cenários de borda que provocam sintomas idênticos e merecem checagem rápida:

1. Oom killer (falta de memória)#

Se o servidor estiver no limite da memória RAM e o lfd tentar processar listas gigantescas de bloqueio (como um csf.deny com centenas de milhares de IPs), o kernel pode escolher o processo do Perl para ser eliminado.

Para verificar se isso aconteceu:

dmesg -T | grep -i "out of memory"
grep -i "killed process" /var/log/messages

Se não houver registros do OOM Killer no horário da falha, a memória não foi o problema.

2. Estouro de tempo do systemd (timeoutstartsec)#

Se o disco estiver com lentidão extrema (I/O wait elevado), a leitura inicial de logs extensos pode demorar mais do que os 90 segundos padrão do systemd. Quando isso acontece, o systemd envia um sinal de encerramento forçado.

Para verificar:

journalctl -u lfd.service --since "10 minutes ago" | grep -i "timeout"

Passo a passo para normalizar o serviço#

Confirmado que o erro é a diretiva de teste, a correção exige apenas quatro comandos no terminal:

1. Desativar o modo TESTING na configuração#

Use o sed para fazer a substituição direta e segura no arquivo:

sed -i 's/^TESTING = "1"/TESTING = "0"/' /etc/csf/csf.conf

2. Validar que a diretiva foi alterada#

Confira se a linha agora exibe o valor zero:

grep "^TESTING =" /etc/csf/csf.conf
# Saida esperada: TESTING = "0"

3. Recarregar o CSF e reiniciar o LFD de forma sincronizada#

Em vez de usar apenas o systemctl, prefira o binário oficial do CSF com a flag -r. Ele faz o flush das regras de firewall, recarrega a tabela e reinicia o daemon em conjunto:

csf -r

4. Verificar o status do serviço#

Confirme que o LFD subiu com status ativo (active (running)):

systemctl status lfd.service

Boas práticas para monitorar o LFD sem surpresas#

Com o serviço rodando normalmente, vale acompanhar os primeiros minutos de execução para checar a inspeção dos logs de segurança:

# Monitora o log ignorando mensagens repetitivas de processos internos
tail -f /var/log/lfd.log | grep -v "P_WATCH"

O grande aprendizado técnico desse caso é saber onde procurar. Mensagens de sinal no systemd (status=9/KILL) apenas dizem que o processo morreu, mas raramente contam o motivo. Ir direto ao log específico da aplicação (/var/log/lfd.log) poupa horas de investigações desnecessárias em bibliotecas do sistema.

Veja também

Infraestrutura Do zero ao VS code como domei o cPanel no Docker e criei um ambiente dev em tempo real

Cibersegurança Análise forense de um comprometimento no CloudLinux e cPanel: da armadilha do sshd_config à persistência no PAM e IPMI

Cibersegurança Arquitetura desacoplada do Imunify email: engenharia reversa de thresholds e monitoramento de quarentena

Este post está licenciado sob CC BY-NC.