Passo a passo para configurar Logrotate no Rocky Linux 9

17 min de leitura  ·  Guia técnico

Logrotate é o utilitário padrão do Linux para automatizar a rotação, compressão e remoção de arquivos de log, evitando que o disco do servidor seja consumido por registros acumulados. Para configurar o Logrotate no Rocky Linux 9, siga estes passos:

1. Verifique se o Logrotate está instalado com rpm -q logrotate
2. Edite o arquivo principal /etc/logrotate.conf com as diretivas globais
3. Crie arquivos de configuração individuais em /etc/logrotate.d/ para cada serviço
4. Teste a configuração com logrotate --debug /etc/logrotate.conf
5. Verifique o timer systemd com systemctl status logrotate.timer
6. Force uma rotação manual para validar o comportamento real com logrotate -f /etc/logrotate.conf

Pré-requisitos para configurar o Logrotate no Rocky Linux 9

• Sistema operacional: Rocky Linux 9 (testado também no AlmaLinux 9)
• Acesso root ou usuário com privilégios sudo
• Logrotate instalado: versão 3.18 ou superior (padrão no Rocky Linux 9)
• Serviços ativos gerando logs em /var/log/ (Nginx, Apache, MySQL, aplicações customizadas)
• Familiaridade básica com edição de arquivos via terminal (vi, nano ou vim)
• Acesso SSH ao servidor — veja como em Acessando servidores VPS Linux da AviraHost

Verificando e instalando o Logrotate no Rocky Linux 9

O gerenciamento de logs no servidor começa pela confirmação de que o utilitário está presente. No Rocky Linux 9, o Logrotate geralmente já vem instalado por padrão, mas vale confirmar antes de qualquer configuração.

Execute o comando abaixo para verificar se o pacote está instalado:

rpm -q logrotate

logrotate-3.18.1-3.el9.x86_64

Se o pacote não estiver instalado, instale-o via DNF:

sudo dnf install logrotate -y

Após a instalação, confirme que o timer do systemd responsável pela execução diária está ativo:

systemctl status logrotate.timer

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2024-11-04 00:00:00 UTC; 6h ago
    Trigger: Tue 2024-11-05 00:00:00 UTC; 17h left

O status active (waiting) confirma que o timer está habilitado e aguardando o próximo ciclo de execução. No Rocky Linux 9, o systemd timer substituiu o cron job tradicional para esta função, garantindo maior confiabilidade na execução.

Verifique também a estrutura de arquivos de configuração existente:

ls /etc/logrotate.d/

btmp  chrony  dnf  firewalld  sssd  wtmp

Cada arquivo nesse diretório corresponde a um serviço ou grupo de logs com suas próprias regras de rotação.

Entendendo a estrutura do arquivo logrotate.conf

A rotação automática de logs depende de diretivas bem definidas no arquivo de configuração global. O arquivo /etc/logrotate.conf define o comportamento padrão que será herdado por todos os arquivos em /etc/logrotate.d/, a menos que sejam sobrescritos individualmente.

Abra o arquivo para análise:

sudo cat /etc/logrotate.conf

# see "man logrotate" for details

# global options do not affect preceding include directives

# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

As principais diretivas globais e seus significados:

• weekly / daily / monthly: frequência de rotação dos logs
• rotate N: número de arquivos rotacionados a manter antes de deletar
• compress: comprime arquivos rotacionados com gzip
• delaycompress: adia a compressão para o próximo ciclo (útil para serviços que ainda escrevem no log antigo)
• create [modo] [usuário] [grupo]: cria um novo arquivo de log vazio após a rotação
• dateext: adiciona a data ao nome do arquivo rotacionado em vez de usar sufixos numéricos
• missingok: não gera erro se o arquivo de log não existir
• notifempty: não rotaciona se o arquivo estiver vazio
• maxsize [tamanho]: força rotação quando o arquivo atingir o tamanho especificado, independente da frequência
• postrotate / endscript: bloco de comandos executados após a rotação

Criando configuração personalizada para o Nginx

A configuração de rotação por serviço é feita criando arquivos individuais em /etc/logrotate.d/. O Nginx, por exemplo, precisa de um sinal especial para reabrir seus arquivos de log após a rotação, sem interromper o serviço.

Crie o arquivo de configuração para o Nginx:

sudo nano /etc/logrotate.d/nginx

Insira o seguinte conteúdo:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 nginx adm
    sharedscripts
    postrotate
        if [ -f /run/nginx.pid ]; then
            kill -USR1 $(cat /run/nginx.pid)
        fi
    endscript
}

Explicando cada diretiva desta configuração:

• daily: rotaciona os logs do Nginx todos os dias
• rotate 14: mantém 14 arquivos rotacionados (duas semanas de histórico)
• compress + delaycompress: comprime os logs, mas aguarda um ciclo para comprimir o mais recente
• create 0640 nginx adm: cria novo arquivo com permissões corretas para o usuário nginx
• sharedscripts: executa o bloco postrotate uma única vez mesmo que múltiplos arquivos sejam rotacionados
• postrotate: envia o sinal USR1 ao processo Nginx para que ele reabra os arquivos de log sem reiniciar

Criando configuração para MySQL no Rocky Linux 9

O controle de logs do MySQL requer atenção especial às permissões de arquivo, pois o processo mysqld precisa ter acesso de escrita ao novo arquivo criado após a rotação. Uma configuração incorreta pode fazer o MySQL parar de registrar eventos.

Crie o arquivo de configuração:

sudo nano /etc/logrotate.d/mysql

/var/log/mysql/mysql.log
/var/log/mysql/mysql-slow.log
/var/log/mysql/error.log {
    daily
    rotate 7
    missingok
    notifempty
    compress
    delaycompress
    create 0640 mysql mysql
    postrotate
        if [ -d /var/run/mysqld ]; then
            mysqladmin -u root flush-logs 2>/dev/null || true
        fi
    endscript
}

O comando mysqladmin flush-logs instrui o MySQL a fechar e reabrir seus arquivos de log, garantindo que novos registros sejam gravados no arquivo recém-criado. O redirecionamento 2>/dev/null || true evita erros caso o MySQL não esteja rodando no momento da rotação.

Para servidores que utilizam MariaDB 11.4, a lógica é idêntica — apenas substitua o caminho do log conforme a configuração do seu my.cnf.

Criando configuração para aplicações customizadas

Aplicações próprias, como sistemas em Python, Node.js ou PHP, frequentemente gravam logs em diretórios fora do padrão. O Logrotate suporta curingas e múltiplos caminhos no mesmo bloco de configuração, o que facilita o gerenciamento de logs de aplicações customizadas.

Exemplo para uma aplicação web em /var/www/meuapp/logs/:

sudo nano /etc/logrotate.d/meuapp

/var/www/meuapp/logs/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    maxsize 100M
    create 0644 www-data www-data
    dateext
    dateformat -%Y%m%d
}

A diretiva maxsize 100M é especialmente útil para aplicações com picos de tráfego: ela força a rotação quando o arquivo atingir 100 MB, independentemente da frequência semanal configurada. Isso evita que um único arquivo de log consuma gigabytes de disco em poucos dias.

Para monitorar o uso de disco e identificar logs problemáticos antes que causem incidentes, use:

du -sh /var/log/* | sort -rh | head -20

2.1G    /var/log/journal
450M    /var/log/nginx
120M    /var/log/mysql
45M     /var/log/audit

Consulte também as Dicas de Otimização de Servidores Linux para outras práticas de manutenção preventiva do servidor.

Testando e forçando a execução do Logrotate

Antes de confiar em qualquer configuração nova, é essencial validar o comportamento esperado sem alterar arquivos reais. O modo debug do Logrotate simula toda a execução e exibe o que seria feito em cada etapa.

Execute o modo de simulação:

sudo logrotate --debug /etc/logrotate.conf

WARNING: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

reading config file /etc/logrotate.conf
including /etc/logrotate.d/btmp
including /etc/logrotate.d/nginx
including /etc/logrotate.d/mysql
...
rotating pattern: /var/log/nginx/*.log  after 1 days (14 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/nginx/access.log
  log does not need rotating (log has been already rotated)

A mensagem "log does not need rotating" é normal quando o log foi rotacionado recentemente. Para forçar a rotação imediatamente e verificar o comportamento real:

Atenção: o comando abaixo força a rotação de todos os logs configurados, ignorando as condições de tempo. Use com cautela em produção, pois pode afetar serviços que dependem dos arquivos de log atuais.

sudo logrotate -f /etc/logrotate.conf

Para testar apenas um arquivo de configuração específico:

sudo logrotate -f /etc/logrotate.d/nginx

Após a execução, verifique se os arquivos foram rotacionados corretamente:

ls -lh /var/log/nginx/

-rw-r----- 1 nginx adm     0 Nov  5 00:00 access.log
-rw-r----- 1 nginx adm  1.2M Nov  4 23:59 access.log-20241104.gz
-rw-r----- 1 nginx adm     0 Nov  5 00:00 error.log
-rw-r----- 1 nginx adm  45K  Nov  4 23:59 error.log-20241104.gz

O arquivo original foi recriado vazio e o arquivo rotacionado foi comprimido com a data no nome, confirmando que a configuração está funcionando corretamente.

Problemas comuns e como resolver

Sintoma: Logrotate não está rotacionando os logs

Causa: O arquivo de log foi rotacionado recentemente e o Logrotate registra o estado em /var/lib/logrotate/logrotate.status. Se a data de última rotação for recente, o utilitário não rotaciona novamente até o próximo ciclo.
Solução: Verifique o arquivo de status com cat /var/lib/logrotate/logrotate.status e confirme a data registrada. Se precisar forçar a rotação, use logrotate -f /etc/logrotate.d/nome-do-servico. Para depurar sem alterar nada, use logrotate --debug /etc/logrotate.conf.

Sintoma: Erro "error: skipping" ou permissão negada

Causa: O arquivo de configuração em /etc/logrotate.d/ tem permissões incorretas ou pertence a um usuário não autorizado. O Logrotate rejeita arquivos de configuração com permissão de escrita para grupo ou outros (world-writable).
Solução: Corrija as permissões do arquivo de configuração com sudo chmod 644 /etc/logrotate.d/nome-do-servico e confirme que o proprietário é root: sudo chown root:root /etc/logrotate.d/nome-do-servico. Verifique também as permissões do diretório de logs alvo.

Sintoma: Nginx ou Apache param de gravar logs após a rotação

Causa: O bloco postrotate não está enviando o sinal correto ao processo para que ele reabra o arquivo de log. O processo continua gravando no arquivo antigo (já renomeado), e o novo arquivo permanece vazio.
Solução: Confirme que o PID file existe e está correto: cat /run/nginx.pid. Verifique se o comando no bloco postrotate está funcionando manualmente: kill -USR1 $(cat /run/nginx.pid). Para o Apache no Rocky Linux 9, use systemctl reload httpd no bloco postrotate.

Sintoma: Logs comprimidos não estão sendo gerados

Causa: A diretiva compress está presente, mas delaycompress está causando confusão — o arquivo mais recente nunca é comprimido porque o serviço ainda pode estar escrevendo nele.
Solução: Esse comportamento é esperado e correto quando delaycompress está ativo. O arquivo da rotação anterior será comprimido no próximo ciclo. Se quiser compressão imediata, remova delaycompress — mas certifique-se de que o serviço não está mais gravando no arquivo antigo antes de fazer isso.

Sintoma: Timer do systemd não está executando o Logrotate

Causa: O timer logrotate.timer pode estar desabilitado ou o serviço logrotate.service pode ter falhado em execuções anteriores.
Solução: Verifique o status com systemctl status logrotate.timer e systemctl status logrotate.service. Se o timer estiver inativo, habilite-o: sudo systemctl enable --now logrotate.timer. Consulte os logs de execução com journalctl -u logrotate.service --since "7 days ago" para identificar erros anteriores.

Perguntas frequentes sobre Logrotate

O que é o Logrotate e para que serve no Linux?

O Logrotate é um utilitário do Linux que automatiza a rotação, compressão e remoção de arquivos de log. Ele evita que logs cresçam indefinidamente e consumam todo o espaço em disco, mantendo o servidor estável. É configurado via arquivos em /etc/logrotate.d/ e executado diariamente pelo cron ou systemd timer. Sem ele, um servidor em produção pode ter o disco preenchido por logs em questão de dias ou semanas, dependendo do volume de tráfego.

Com que frequência o Logrotate roda no Rocky Linux 9?

No Rocky Linux 9, o Logrotate é executado diariamente pelo systemd timer logrotate.timer, que substitui o cron job tradicional. Você pode verificar o status com systemctl status logrotate.timer e forçar execução manual com logrotate -f /etc/logrotate.conf. O timer é mais confiável que o cron porque o systemd garante a execução mesmo que o horário programado seja perdido (por exemplo, se o servidor estava desligado).

Como evitar que o disco encha por causa de logs no servidor?

Configure o Logrotate com as diretivas rotate N (número de arquivos a manter), compress (compressão gzip) e maxsize (tamanho máximo antes de rotacionar). Combine com daily ou weekly para garantir rotação regular. Monitore o uso de disco com df -h e du -sh /var/log/* para identificar logs problemáticos antes que causem incidentes em produção.

É possível configurar o Logrotate para um serviço específico como Nginx ou MySQL?

Sim. Crie um arquivo em /etc/logrotate.d/ com o nome do serviço, por exemplo /etc/logrotate.d/nginx, e defina o caminho do log, frequência, número de rotações e comandos pós-rotação no bloco postrotate. O Nginx, por exemplo, requer kill -USR1 $(cat /run/nginx.pid) no bloco postrotate para reabrir o arquivo de log sem reiniciar o processo. Cada serviço tem suas particularidades — sempre teste com logrotate --debug antes de aplicar em produção.

Como testar a configuração do Logrotate sem rotacionar os logs de verdade?

Use o modo de simulação com o comando logrotate --debug /etc/logrotate.conf ou logrotate -d /etc/logrotate.conf. Esse modo exibe o que seria feito sem alterar nenhum arquivo. Para forçar a rotação real imediatamente, use logrotate -f /etc/logrotate.conf com cautela, pois isso ignora as condições de tempo configuradas e pode afetar serviços em execução.

Conclusão

• Configure o Logrotate por serviço: crie arquivos individuais em /etc/logrotate.d/ para Nginx, MySQL e aplicações customizadas, com diretivas específicas para cada caso — especialmente o bloco postrotate para serviços que precisam reabrir arquivos de log.
• Sempre teste antes de aplicar: use logrotate --debug /etc/logrotate.conf para simular a execução sem alterar arquivos reais, e monitore o diretório /var/log/ regularmente com du -sh /var/log/* para identificar crescimento anormal.
• Mantenha o timer ativo: no Rocky Linux 9, confirme que logrotate.timer está habilitado com systemctl status logrotate.timer e revise os logs de execução periodicamente com journalctl -u logrotate.service para garantir que não há falhas silenciosas.

Leia também

• Passo a passo para configurar monitoração de logs com Logwatch em VPS Linux e servidor dedicado
• Guia para Configurar Logs Personalizados no Nginx em VPS Linux
• Guia para Configurar Limite de Uso de CPU por Processo no Linux

Precisa de ajuda com seu servidor Linux?

Manter logs sob controle é apenas uma das tarefas de administração de um servidor Linux em produção. Um VPS bem configurado com recursos adequados facilita a implementação de boas práticas como o Logrotate e reduz o risco de incidentes por falta de espaço em disco.

Conheça os planos de VPS da AviraHost e comece com um servidor Linux otimizado