Diagnosticando o erro "ReceiveAckHdr: timeout 300 is exceeded" no mod_lsapi (CloudLinux)

Se você administra servidores CloudLinux com mod_lsapi, provavelmente já viu no error_log do Apache a mensagem abaixo:

[lsapi:error] [pid 12345:tid 67890] [client 1.2.3.4:0] [host domain.com] Error on sending request(GET / HTTP/1.0); uri(/index.php) content-length(0): ReceiveAckHdr: timeout 300 is exceeded

Esse erro indica um gargalo entre Apache e processo PHP, não necessariamente falta de CPU ou memória.

O que significa ReceiveAckHdr timeout 300

O mod_lsapi faz a ponte entre Apache e LSPHP. Quando a requisição chega, o Apache entrega para o PHP e aguarda o ACK (confirmação de processamento).

Quando o log mostra timeout 300, o Apache esperou 5 minutos e não recebeu resposta útil do PHP. Para proteger o servidor, ele encerra a requisição.

Passo 1: descarte o mito de recurso insuficiente

Antes de elevar limites de LVE, valide os sinais reais.

• Se fosse limite de recurso, você veria erros como 508 Resource Limit Reached.
• Se lveinfo mostra uso baixo de CPU, o problema tende a ser lógico.
• Processos parados sem CPU geralmente estão aguardando I/O, banco ou rede.

Passo 2: encontre a causa raiz

Quando o PHP fica 300 segundos sem avançar, ele costuma estar travado em dependência externa.

1. Plugins de sincronização em loop

Cenário comum em e-commerce: plugin de feed tenta renomear arquivo temporário, falha e entra em loop.

Sinal no log:

PHP Warning: rename(...) No such file or directory

2. Deadlock ou fila no banco de dados

Consultas bloqueadas podem congelar várias requisições PHP.

SHOW PROCESSLIST;

ou

mysqladmin procstat

3. API externa lenta ou indisponível

Se checkout, frete, licença ou webhook depende de serviço externo lento, o PHP fica aguardando resposta até bater timeout.

Passo 3: soluções práticas

A) Troque WP-Cron por cron real

No WordPress, tarefas pesadas em requisição web pioram timeout.

No wp-config.php:

define('DISABLE_WP_CRON', true);

Depois, configure cron do sistema para executar o cron do WordPress a cada 5 ou 10 minutos.

B) Limpe temporários e cache do plugin afetado

Revise diretórios de uploads e remova resíduos de execução quebrada (.tmp, .csv, .log) quando houver conflito de leitura/escrita/permissão.

C) Ajuste parâmetros do PHP com coerência

• memory_limit: para e-commerce, use base mínima prática de 512M.
• max_execution_time: mantenha igual ou menor que o timeout do LSAPI para

evitar processos zumbis.

ReceiveAckHdr: timeout 300 é sintoma de backend estagnado. Aumentar timeout para 600 ou 1000 normalmente só prolonga a espera. O ganho real vem de:

1. corrigir loops de plugin
2. destravar consultas SQL
3. reduzir dependências externas lentas
4. mover tarefas pesadas para cron do sistema

Dica avançada para diagnóstico fino:

strace -p [PID_DO_PROCESSO_PHP]

Esse comando mostra em qual syscall o processo está parado (arquivo, socket, rede), acelerando muito o troubleshooting.

Este post está licenciado sob CC BY-NC.