Como configurar Logrotate em Rocky Linux 9 (com exemplos reais)

16 min de leitura  ·  Guia técnico

Logrotate é a ferramenta padrão do Linux para gerenciar a rotação automática de arquivos de log, evitando que discos sejam consumidos por registros acumulados. Para configurar o Logrotate no Rocky Linux 9 com exemplos reais, siga estes passos:

1. Confirme a instalação do Logrotate com rpm -q logrotate
2. Edite ou crie um arquivo de configuração em /etc/logrotate.d/
3. Defina diretivas como daily, rotate, compress e postrotate
4. Teste a configuração com logrotate --debug /etc/logrotate.d/seuarquivo
5. Force a execução manual com logrotate -f /etc/logrotate.conf para validar
6. Verifique o timer systemd com systemctl status logrotate.timer

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

• Acesso root ou usuário com privilégios sudo ao servidor
• Rocky Linux 9 instalado e atualizado (dnf update -y)
• Logrotate instalado (padrão no sistema base — verifique com rpm -q logrotate)
• Familiaridade básica com edição de arquivos via terminal (vi, nano ou vim)
• Serviços como Nginx, Apache ou aplicações customizadas gerando logs em /var/log/

Como funciona a estrutura de configuração do Logrotate

O gerenciamento de logs com Logrotate no Rocky Linux 9 é dividido em dois níveis: o arquivo principal /etc/logrotate.conf e os arquivos individuais dentro do diretório /etc/logrotate.d/. Cada serviço instalado no sistema — como Nginx, Apache, rsyslog ou aplicações customizadas — pode ter seu próprio arquivo de configuração nesse diretório, o que facilita a manutenção e evita conflitos.

O arquivo /etc/logrotate.conf define os padrões globais e inclui automaticamente todos os arquivos de /etc/logrotate.d/ via diretiva include. Para visualizar o conteúdo padrão:

cat /etc/logrotate.conf

# Output esperado (trecho):
weekly
rotate 4
create
dateext
compress
include /etc/logrotate.d

As diretivas globais se aplicam a todos os blocos, mas podem ser sobrescritas individualmente em cada arquivo de /etc/logrotate.d/. Isso significa que você pode ter logs do Nginx rotacionando diariamente enquanto logs de auditoria rodam semanalmente, sem conflito.

Para listar os arquivos de configuração já existentes no sistema:

ls -la /etc/logrotate.d/

# Output esperado:
-rw-r--r--. 1 root root  91 Jan 10 2023 btmp
-rw-r--r--. 1 root root 160 Jan 10 2023 dnf
-rw-r--r--. 1 root root 224 Jan 10 2023 rsyslog
-rw-r--r--. 1 root root 145 Jan 10 2023 wtmp

Diretivas essenciais do Logrotate com exemplos práticos

Compreender as diretivas de rotação de logs é fundamental antes de criar configurações personalizadas. Cada diretiva controla um aspecto específico do comportamento do Logrotate. Abaixo estão as mais utilizadas em ambientes de produção:

• daily / weekly / monthly / yearly — frequência de rotação
• rotate N — número de arquivos antigos mantidos antes de deletar
• compress — comprime arquivos rotacionados com gzip
• delaycompress — adia a compressão para o próximo ciclo (útil para daemons que ainda escrevem no arquivo)
• missingok — não gera erro se o arquivo de log não existir
• notifempty — não rotaciona se o arquivo estiver vazio
• create 0640 usuario grupo — cria novo arquivo de log com permissões e dono definidos
• dateext — adiciona a data ao nome do arquivo rotacionado em vez de número sequencial
• minsize N — só rotaciona se o arquivo atingir o tamanho mínimo (ex: 100M)
• maxsize N — força rotação se o arquivo ultrapassar o tamanho máximo
• postrotate / endscript — executa comandos após a rotação (ex: reload do serviço)
• sharedscripts — executa o bloco postrotate uma única vez mesmo com múltiplos arquivos

Para servidores com alto volume de requisições, como um servidor Linux otimizado para produção, combinar maxsize com daily garante que logs não cresçam além do esperado mesmo em dias de pico.

Configurando o Logrotate para Nginx no Rocky Linux 9

A rotação de logs do Nginx é um dos casos de uso mais comuns em servidores web. O Nginx mantém dois arquivos principais: access.log e error.log. Sem rotação adequada, esses arquivos podem crescer para gigabytes em poucos dias em servidores com tráfego moderado.

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

nano /etc/logrotate.d/nginx

Insira o seguinte conteúdo:

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 nginx adm
    dateext
    sharedscripts
    postrotate
        nginx -s reopen
    endscript
}

Neste exemplo, os logs são rotacionados diariamente, mantendo 14 versões comprimidas. O comando nginx -s reopen instrui o processo do Nginx a fechar e reabrir os arquivos de log, garantindo que ele escreva no novo arquivo criado após a rotação — sem necessidade de reiniciar o serviço.

Para testar a configuração sem aplicar alterações reais:

logrotate --debug /etc/logrotate.d/nginx

# Output esperado (trecho):
reading config file /etc/logrotate.d/nginx
Handling 1 logs
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)

Criando configuração personalizada para aplicações customizadas

Aplicações desenvolvidas internamente ou instaladas manualmente frequentemente gravam logs em diretórios fora do padrão do sistema. Configurar o Logrotate para esses casos exige atenção especial às permissões e ao processo responsável pelo arquivo.

Suponha que você tenha uma aplicação Node.js gravando logs em /opt/minhaapp/logs/app.log com o usuário appuser. Crie o arquivo:

nano /etc/logrotate.d/minhaapp

/opt/minhaapp/logs/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0660 appuser appuser
    dateext
    maxsize 500M
    postrotate
        systemctl reload minhaapp 2>/dev/null || true
    endscript
}

O uso de maxsize 500M combinado com weekly garante que, mesmo que a semana não tenha terminado, o arquivo será rotacionado se ultrapassar 500 MB. O 2>/dev/null || true no postrotate evita que erros no reload causem falha no Logrotate.

Atenção: ao usar create com usuário e grupo específicos, certifique-se de que o usuário existe no sistema. Um usuário inexistente causará falha silenciosa na criação do novo arquivo de log.

Para forçar a execução imediata e verificar o resultado:

logrotate -f /etc/logrotate.d/minhaapp
ls -lh /opt/minhaapp/logs/

# Output esperado:
-rw-rw----. 1 appuser appuser    0 Nov 15 10:32 app.log
-rw-rw----. 1 appuser appuser 2.3M Nov 14 23:59 app.log-20241114.gz

Configurando rotação de logs do MySQL e MariaDB

O gerenciamento de logs de banco de dados requer cuidado especial, pois o MySQL e o MariaDB mantêm arquivos de log abertos continuamente. O arquivo de configuração padrão já existe em /etc/logrotate.d/mysql ou /etc/logrotate.d/mariadb, mas pode precisar de ajustes para ambientes de produção.

Verifique se já existe uma configuração:

cat /etc/logrotate.d/mysql

Se precisar criar ou ajustar para o MariaDB:

nano /etc/logrotate.d/mariadb

/var/log/mariadb/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 mysql mysql
    sharedscripts
    postrotate
        /usr/bin/mysqladmin -u root --password=$(cat /root/.mysql_secret) flush-logs 2>/dev/null || true
    endscript
}

Para ambientes onde a senha do root do MySQL está armazenada em arquivo de configuração seguro, adapte o postrotate conforme sua infraestrutura. O comando flush-logs instrui o MariaDB a fechar e reabrir seus arquivos de log sem interromper conexões ativas.

Se você gerencia múltiplos serviços em seu VPS, consulte o artigo Configurando um Servidor Linux para Hospedagem de Sites para uma visão completa da configuração do ambiente.

Verificando o status e histórico de execução do Logrotate

O monitoramento da execução do Logrotate é essencial para garantir que as rotações estão ocorrendo conforme esperado. O Rocky Linux 9 utiliza o systemd timer em vez do cron job tradicional para acionar o Logrotate diariamente.

Para verificar o status do timer:

systemctl status logrotate.timer

# Output esperado:
● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; preset: enabled)
     Active: active (waiting) since Fri 2024-11-15 00:00:00 UTC; 10h ago
    Trigger: Sat 2024-11-16 00:00:00 UTC; 13h left
   Triggers: ● logrotate.service

Para ver o histórico das últimas execuções:

journalctl -u logrotate.service --since "7 days ago"

O Logrotate mantém um arquivo de estado em /var/lib/logrotate/logrotate.status que registra quando cada arquivo foi rotacionado pela última vez:

cat /var/lib/logrotate/logrotate.status

# Output esperado (trecho):
logrotate state -- version 2
"/var/log/nginx/access.log" 2024-11-15-0:0:0
"/var/log/nginx/error.log" 2024-11-15-0:0:0
"/var/log/mariadb/mariadb.log" 2024-11-15-0:0:0

Se uma entrada não aparecer neste arquivo, o Logrotate nunca processou aquele log — o que pode indicar um erro de configuração ou caminho incorreto.

Problemas comuns e como resolver

Sintoma: Logrotate não rotaciona o arquivo mesmo com -f

Causa: O arquivo de log está vazio e a diretiva notifempty está ativa, ou o arquivo não existe e missingok não foi definido.
Solução: Verifique se o arquivo existe com ls -lh /caminho/do/log. Se estiver vazio e você precisar forçar a rotação, remova temporariamente notifempty da configuração ou use logrotate -f --force /etc/logrotate.d/seuarquivo. Confirme também que o caminho no arquivo de configuração corresponde exatamente ao arquivo real, incluindo extensão.

Sintoma: Erro "error: skipping /var/log/nginx/access.log because parent directory has insecure permissions"

Causa: O Logrotate recusa processar arquivos em diretórios com permissões consideradas inseguras (world-writable sem sticky bit, ou pertencentes a usuário não-root).
Solução: Verifique as permissões do diretório pai com ls -ld /var/log/nginx/. O diretório deve pertencer a root ou ao usuário do serviço, com permissões 0755 ou 0750. Corrija com chmod 0755 /var/log/nginx/ e chown root:adm /var/log/nginx/. Se precisar manter permissões diferentes, adicione su nginx adm dentro do bloco de configuração.

Sintoma: Logs do Nginx continuam crescendo após rotação

Causa: O processo do Nginx ainda está escrevendo no arquivo antigo porque não recebeu o sinal para reabrir os descritores de arquivo. Isso ocorre quando o bloco postrotate está ausente ou o comando falha silenciosamente.
Solução: Verifique se o postrotate está configurado corretamente e teste manualmente: nginx -s reopen. Se o Nginx não estiver em execução, o comando retornará erro — adicione || true para evitar que isso interrompa o Logrotate. Confirme também que o binário do Nginx está no PATH correto com which nginx.

Sintoma: Arquivos rotacionados não estão sendo comprimidos

Causa: A diretiva delaycompress está ativa sem compress, ou o gzip não está instalado no sistema.
Solução: Confirme que ambas as diretivas estão presentes: compress e delaycompress. Verifique se o gzip está disponível com which gzip. Se quiser usar compressão diferente, adicione compresscmd /usr/bin/bzip2 e compressext .bz2 ao bloco de configuração.

Sintoma: logrotate.timer inativo ou desabilitado

Causa: O timer foi desabilitado manualmente ou não foi ativado após reinstalação do pacote.
Solução: Reative e inicie o timer com os comandos abaixo:

systemctl enable logrotate.timer
systemctl start logrotate.timer
systemctl status logrotate.timer

Perguntas frequentes sobre Logrotate no Rocky Linux 9

O Logrotate já vem instalado no Rocky Linux 9?

Sim, o Logrotate é instalado por padrão no Rocky Linux 9 como parte do sistema base. Você pode confirmar executando rpm -q logrotate no terminal. Caso não esteja presente por algum motivo, instale com dnf install logrotate -y e o pacote será baixado dos repositórios oficiais sem dependências adicionais.

Com que frequência o Logrotate executa automaticamente?

Por padrão, o Logrotate é acionado diariamente pelo systemd timer logrotate.timer, que substitui o cron job em distribuições modernas como Rocky Linux 9. Você pode verificar o timer com systemctl status logrotate.timer e forçar execução manual com logrotate -f /etc/logrotate.conf. O horário exato de execução pode variar por conta do mecanismo de randomização do systemd (RandomizedDelaySec), mas ocorre dentro da janela diária configurada.

Como evitar que o Logrotate apague logs importantes antes do tempo?

Use a diretiva rotate N para definir quantas versões antigas serão mantidas, e minsize para garantir que o arquivo só seja rotacionado se atingir um tamanho mínimo. Combine com compress e delaycompress para manter os logs comprimidos sem perder o arquivo mais recente. Para logs críticos de auditoria, considere usar rotate 30 com monthly para manter até 30 meses de histórico comprimido.

O Logrotate reinicia serviços automaticamente após rotacionar logs?

Não automaticamente — você precisa configurar a diretiva postrotate com o comando de reload do serviço desejado. Por exemplo, para o Nginx, adicione postrotate com o comando nginx -s reopen dentro do bloco de configuração do log. Isso garante que o daemon abra o novo arquivo de log sem interrupção de serviço. Sem essa diretiva, o processo continuará escrevendo no arquivo antigo mesmo após a rotação.

Como testar uma configuração do Logrotate sem rotacionar de verdade?

Execute logrotate --debug /etc/logrotate.d/meuarquivo para simular a rotação sem aplicar nenhuma alteração real. O modo debug exibe exatamente o que seria feito, incluindo quais arquivos seriam comprimidos, renomeados ou removidos, sem modificar nada no disco. Esta é a forma mais segura de validar uma nova configuração antes de colocá-la em produção, especialmente em servidores críticos.

Conclusão

• Configure um arquivo por serviço em /etc/logrotate.d/ com diretivas específicas — evite modificar o logrotate.conf global para configurações de aplicações individuais.
• Sempre inclua postrotate para serviços como Nginx, Apache e MariaDB, garantindo que os daemons reabram os descritores de arquivo após a rotação e não continuem gravando no arquivo antigo.
• Teste com --debug antes de aplicar qualquer nova configuração em produção, e monitore o logrotate.status e os logs do systemd regularmente para confirmar que as rotações estão ocorrendo conforme esperado.

Leia também

• Rocky Linux 9: como configurar Postfix com DKIM corretamente
• Passo a passo para configurar Postfix com TLS no Rocky Linux 9
• Entenda UFW ou firewalld para Rocky Linux 9: análise honesta

Precisa de ajuda com seu servidor Linux?

Configurar e manter serviços como Logrotate, Nginx e bancos de dados em produção exige um ambiente estável e com recursos adequados. Os planos de VPS da AviraHost oferecem Rocky Linux 9 pré-configurado, suporte técnico especializado e infraestrutura otimizada para quem precisa de controle total sobre o servidor.

Conheça os planos de VPS da AviraHost