O problema
Eu tenho vários servidores idênticos, todos executando configurações logrotate idênticas, girando um arquivo de log personalizado. Em pelo menos um dos servidores, meus logs não estão sendo rotacionados corretamente.
Eu tenho resolvido esse problema de vez em quando há semanas, sem sucesso. Aqui estão mais algumas informações e os passos que tomei até agora. Qualquer ajuda seria apreciada.
Estou basicamente sem maneiras de solucionar esse problema e adoraria algumas ideias para tentar ver o que está errado aqui.
O que eu tentei
(os arquivos de configuração estão abaixo)
- Verifique a configuração e as permissões no arquivo principal
logrotate . Tudo parece bem para mim lá.
- Defina permissões no diretório de destino,
derp , para o que o logrotate precisa (o diretório não pode ser mundialmente editável afaik ).
-
Força logrotate a ser executada com o seguinte:
logrotate --force /etc/logrotate.d/derp
Este comando gira os registros corretamente, mas no dia seguinte eles não serão executados.
-
Altere manualmente a data para algum dia no passado em /var/lib/logrotate/status e, em seguida, veja se o log é executado corretamente na próxima vez que logrotate começar ou com:
logrotate -vv /etc.logrotate.d/derp
Isso girará o log uma vez, mas na próxima vez em que o log estiver em rotação, ele não será rotacionado. Aqui está a saída de uma rotação manual bem sucedida:
rotating pattern: /derp/*.log after 1 days (14 rotations)
empty log files are not rotated, old logs are removed
considering log /derp/access.log
log needs rotating
considering log /derp/php_errors.log
log does not need rotating
rotating log /derp/access.log, log->rotateCount is 14
dateext suffix '-20150814'
...
files getting renamed and moved
...
running prerotate script
renaming /derp/access.log to /derp/access.log.1
creating new /derp/access.log mode = 0774 uid = 0 gid = 4
running postrotate script
A vida é boa, não? O único problema é que no dia seguinte, quando precisa ser rotacionado (ou seja, sempre tem dados e nunca está vazio), nada acontece.
-
Eu consultei muitas perguntas da SEU, entre as quais esta questão que foi útil no passado lidando com outros problemas de logrotate.
Config
O sistema está executando o Debian 7 atualizado. O processo que gera os arquivos de log é executado como raiz. O processo que gera os arquivos de log é um aplicativo php e gera vários filhos.
Aqui estão as configurações relevantes, em que derp é a localização dos meus arquivos de log personalizados:
/etc/logrotate.d/derp
Permissões no arquivo de configuração:
-rw-r--r-- 1 root root 265 Jul 9 2014 derp
/derp/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 774 root adm
sharedscripts
postrotate
nohup /derp/daemonrestart.sh > /dev/null 2>&1
endscript
prerotate
killall -9 php > /dev/null 2>&1
endscript
}
Os scripts prerotate e postrotate basicamente iniciam o processo (um servidor de soquete) ou o interrompem e funcionam bem em todos os outros servidores. Tenho certeza de que não há problemas lá.
/var/lib/logrotate/status
(redigido para mostrar informações relevantes)
logrotate state -- version 2
"/var/log/kern.log" 2015-7-20
...
"/derp/php_errors.log" 2015-8-11
...
"/derp/access.log" 2015-8-14
...
/derp/
Permissões no diretório de destino:
drwxr-xr-x 2 root root 4096 Jun 18 10:05 derp
E o log relevante localizado em \derp\ :
-rwxrwxr-- 1 root adm 3755558 Aug 14 07:57 access.log