Depurando logs de FTP no cPanel quando as estatísticas não atualizam

Depurando logs de FTP no cPanel quando as estatísticas não atualizam#

Recentemente eu enfrentei um desafio comum, mas bastante frustrante para quem administra servidores cPanel pela CLI: realizei transferências de arquivos via FTP, confirmei que os arquivos chegaram ao destino, mas os logs dentro da pasta do usuário simplesmente não refletiam a atividade recente.

O caminho que gerou a dúvida foi:

/home/user/logs

Dentro dele havia arquivos compactados no padrão:

ftp.domain.com-ftp_log-Mar-2026.gz

Mesmo após enviar arquivos de vários megabytes via FTP, o tamanho desses .gz não mudava e as datas de modificação pareciam congeladas. A primeira impressão era de que o Pure-FTPd não estava registrando transferência, ou de que o cPanel tinha parado de atualizar estatísticas.

O ponto central do diagnóstico foi separar o que é log vivo do que é archive. Arquivo .gz dentro de /home/user/logs não é o log em tempo real do serviço. Ele é um pacote histórico, gerado por rotação e processamento periódico. Se eu faço upload agora, não devo esperar que esse .gz seja atualizado imediatamente como se fosse um tail -f.

O cenário que encontrei#

O usuário tinha arquivos de log compactados, com nomes parecidos com:

ftp.domain.com-ftp_log-Mar-2026.gz

E o comportamento observado era:

• transferências via FTP concluíam no FileZilla;
• arquivos apareciam no destino, como public_html;
• o tamanho dos .gz em /home/user/logs não mudava;
• as datas de modificação pareciam antigas;
• runweblogs não indicava atividade recente;
• a leitura inicial sugeria que o log FTP estava parado.

Nesse tipo de caso, eu não começo assumindo falha no FTP. Primeiro eu valido se a transferência realmente aconteceu. Se o arquivo existe no destino e o FileZilla reportou sucesso, o serviço FTP provavelmente funcionou. A pergunta muda para:

onde o cPanel registrou o evento bruto e quando ele vai compactar isso para a home do usuário?

O mito do runweblogs#

O primeiro instinto em cPanel é executar:

/usr/local/cpanel/scripts/runweblogs <usuario>

Eu executei esse caminho porque ele é um script oficial e, em muitos cenários, resolve estatísticas que parecem atrasadas. Mas o aprendizado operacional foi importante: runweblogs processa estatísticas para o painel visual, como Awstats e Webalizer. Ele lê dados existentes e gera relatórios.

Ele não é o componente que escreve instantaneamente no arquivo .gz de FTP dentro da home do usuário.

Se o log bruto ainda não foi rotacionado, se o cpanellogd ainda não consolidou a informação ou se a atividade não está no arquivo que o script espera, o runweblogs pode retornar uma mensagem estranha, como ausência de atividade desde a época Unix inicial.

O caso clássico é a mensagem indicando algo como:

No activity since 1969

Essa data não significa que o servidor voltou no tempo. Ela normalmente indica que o processador de estatísticas não encontrou atividade nova no conjunto de logs que ele está usando como entrada, ou que não existe timestamp válido processável naquele caminho.

A diferença entre log bruto e archive#

Essa foi a virada do diagnóstico. Eu passei a tratar os arquivos .gz como arquivos mortos, no sentido operacional: eles são archives, representam o passado e dependem de uma tarefa de manutenção para serem gerados ou atualizados.

O fluxo mental correto é:

serviço FTP gera evento -> sistema registra em log bruto -> cPanel processa/rotaciona -> archive aparece em /home/user/logs

O erro é esperar:

upload via FTP -> .gz muda imediatamente

Esse segundo fluxo não é como o cPanel trabalha.

Por isso, quando quero depurar o presente, eu paro de olhar primeiro para /home/user/logs/*.gz e vou para os logs brutos em /var/log, journald e domlogs temporários do cPanel.

Procurando logs no journald#

Em sistemas modernos, principalmente quando o /var/log/xferlog não existe, o Pure-FTPd pode estar enviando mensagens para syslog ou journald.

O comando mais direto para acompanhar o serviço em tempo real é:

journalctl -u pure-ftpd -f

Com ele, eu observo a tentativa de conexão enquanto o cliente faz login e executa upload. O objetivo é confirmar:

• se o Pure-FTPd recebeu a conexão;
• se houve autenticação;
• se o comando PUT chegou;
• se a transferência foi concluída;
• se houve erro de permissão, caminho ou sessão;
• se o daemon realmente está emitindo log.

Esse teste remove uma dúvida importante. Se o journald mostra o evento, o FTP está registrando em algum lugar. O problema não é "não existe log", é "o log ainda não foi consolidado para o arquivo compactado da home".

Verificando /var/log/messages#

Em alguns ambientes, a saída do Pure-FTPd aparece no log geral do sistema. Então eu também procurei pelo nome do arquivo transferido:

grep "nome_do_arquivo.txt" /var/log/messages

Essa busca é objetiva. Eu não procuro genericamente por tudo de FTP primeiro, eu procuro pelo artefato real que transferi. Se eu enviei nome_do_arquivo.txt, esse nome é uma evidência melhor do que ficar interpretando eventos genéricos.

Se o arquivo aparece em /var/log/messages, eu confirmo que a atividade aconteceu e foi logada no nível do sistema. A ausência no .gz da home continua sendo apenas atraso de processamento ou rotação.

Quando /var/log/xferlog não existe#

Muita documentação antiga manda olhar:

/var/log/xferlog

Em alguns servidores isso existe e é perfeito para rastrear FTP. Em outros, especialmente dependendo da versão do cPanel, sistema operacional e configuração do Pure-FTPd, esse arquivo não existe.

Quando não encontro /var/log/xferlog, eu não considero isso automaticamente um erro. Eu passo a validar:

journalctl -u pure-ftpd -f
grep "nome_do_arquivo.txt" /var/log/messages

E também confiro se o cPanel está armazenando dados temporários nos domlogs.

Domlogs: o pulo do gato#

O cPanel mantém logs temporários antes de compactar dados para a home do usuário. Um ponto que eu verifico é:

ls -la /var/log/apache2/domlogs/<usuario>/

Apesar do nome apache2, esse caminho pode concentrar logs por domínio/usuário usados pelo ecossistema de estatísticas do cPanel. Dependendo do ambiente, é ali que eu encontro evidências antes de elas aparecerem em /home/user/logs.

O raciocínio é:

se a informação está nos domlogs, o sistema registrou a atividade, mas ainda não empacotou o archive mensal.

Isso explica por que o .gz continua igual mesmo depois de um upload grande. O upload aconteceu, mas o archive ainda não foi reconstruído ou rotacionado.

Forçando processamento com cpanellogd#

Quando eu preciso forçar o processamento dos logs, o caminho correto não é insistir apenas no runweblogs. Eu uso o cpanellogd, que é o daemon responsável por processamento e rotação de logs do cPanel.

O comando operacional é:

/usr/local/cpanel/cpanellogd --one

Em alguns sistemas, o binário pode estar em outro caminho ou o ambiente pode ter mudança de versão. Então, se houver erro de caminho, eu localizo com:

which cpanellogd

ou:

find /usr/local/cpanel -name cpanellogd -type f 2>/dev/null

Essa etapa força uma passada de processamento, mas ainda assim eu tomo cuidado com a expectativa. O objetivo é acionar a manutenção do cPanel, não transformar os .gz em logs vivos de tempo real.

Erros comuns que encontrei#

Durante esse tipo de atendimento, alguns erros se repetem.

Erro de usuário digitado errado#

Um exemplo clássico:

Invalid User: acount

Nesse caso, a causa pode ser simplesmente typo. O usuário correto pode ser account, com duas letras c, enquanto o comando foi executado com acount.

O cPanel é literal e case-sensitive em vários pontos. Antes de culpar o daemon, eu valido:

id usuario
ls -ld /home/usuario
grep "^usuario:" /etc/passwd

Mensagem de atividade desde 1969#

Quando aparece algo como:

No activity since 1969

eu interpreto como ausência de dados processáveis naquele ciclo, timestamp zerado ou falta de log bruto consolidado para o processador de estatísticas.

A ação correta é validar logs brutos e, se necessário, rodar:

/usr/local/cpanel/cpanellogd --one

Script ou log em path legado#

Outro erro comum:

No such file or directory

Isso pode acontecer porque o comando usado veio de documentação antiga, ou porque a versão atual do cPanel moveu binários e paths. Nesses casos, eu localizo o binário:

which cpanellogd

E valido caminhos reais antes de insistir no comando.

Tabela operacional de causa e solução#

Checklist que eu usei#

Meu fluxo final ficou assim:

1. Confirmar que o arquivo realmente chegou:

ls -lah /home/user/public_html/nome_do_arquivo.txt

1. Verificar os archives do usuário:

ls -lah /home/user/logs/

1. Rodar runweblogs sabendo exatamente o que ele faz:

/usr/local/cpanel/scripts/runweblogs user

1. Acompanhar Pure-FTPd em tempo real:

journalctl -u pure-ftpd -f

1. Procurar o nome do arquivo no log geral:

grep "nome_do_arquivo.txt" /var/log/messages

1. Procurar dados temporários nos domlogs:

ls -la /var/log/apache2/domlogs/user/

1. Forçar processamento quando necessário:

/usr/local/cpanel/cpanellogd --one

1. Localizar binário caso o path varie:

which cpanellogd

O que eu validei antes de encerrar#

Para encerrar o chamado com segurança, eu validei três coisas.

Primeiro, se a transferência realmente ocorreu:

ls -lah /home/user/public_html/

Segundo, se havia evidência do FTP em logs brutos:

journalctl -u pure-ftpd -f
grep "nome_do_arquivo.txt" /var/log/messages

Terceiro, se o cPanel tinha caminhos de processamento e rotação coerentes:

/usr/local/cpanel/scripts/runweblogs user
/usr/local/cpanel/cpanellogd --one

Com isso eu consegui separar falha real de transferência de atraso normal de estatística.

O aprendizado prático#

Esse incidente reforçou uma diferença que parece pequena, mas evita muito retrabalho: /home/user/logs/*.gz representa histórico processado, não atividade viva. Para depurar o presente, eu preciso olhar logs brutos em /var/log, journald e áreas temporárias como domlogs.

Se a transferência foi bem-sucedida no FileZilla e o arquivo existe em public_html, o servidor FTP cumpriu sua parte. A atualização do .gz é um processo de manutenção periódico do cPanel, não um gatilho instantâneo a cada upload. Quando eu entendo essa separação, paro de perseguir o arquivo compactado como se ele fosse log em tempo real e passo a investigar no lugar certo, com journalctl, /var/log/messages, domlogs e cpanellogd. É esse tipo de detalhe operacional que transforma um chamado confuso em um diagnóstico limpo, rastreável e fácil de explicar.

Veja também

Infraestrutura Debugando pure-ftpd travado na mensagem de boas-vindas em cPanel/OVH

Servidores O mistério dos arquivos deletados: como rastrear remoções no cPanel, FTP e na camada PHP

Infraestrutura Anatomia do crontab, comportamento do kernel e manutenção do spool de e-mails no Exim

Este post está licenciado sob CC BY-NC.