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.

Veja também

Infraestrutura Anatomia de um deadlock silencioso no CloudLinux e cPanel: processos fantasmas, travas de sessão e filas TCP

Cibersegurança Checklist definitivo de segurança e hardening para WordPress: 99 medidas técnicas em 11 áreas críticas

Servidores Autópsia de um timeout global: debugando gargalos de i/o, MySQL e Apache no cPanel

Este post está licenciado sob CC BY-NC.