Estou tendo problemas com qualquer comando que diga ao nginx para usar novos arquivos de log. Estou usando Ubuntu 18.04, nginx/1.14.0, logrotate 3.11.0
Se eu criar arquivos novos access.logou error.logem /var/log/nginx, manualmente ou via logrotate, eles não serão usados e, em vez disso, o serviço usará os arquivos de log antigos (que renomeei para access.log.1este teste, simulando o que o logrotate faz).
Eu tentei os seguintes comandos (separadamente). Nenhum deles produz qualquer mensagem de erro, todos produzem a saída esperada. Mas o nginx se recusa a parar de usar os logs antigos.
service nginx rotate
invoke-rc.d nginx rotate
kill -USR1 `cat /var/run/nginx.pid`
Também verifiquei se o .pidarquivo acima está no lugar correto.
A única maneira de fazer a rotação do log funcionar é por meio de um service nginx reload, que faz o trabalho, mas também recarrega os arquivos de configuração. Sei que não há tempo de inatividade com a recarga, mas ainda assim prefiro recarregar o mínimo possível, por isso quero começar a service nginx rotatetrabalhar.
Tenho quase certeza de que é devido a problemas de permissão no /var/log. Recentemente, configuramos um cronjob para garantir que os arquivos de log tenham permissões seguras. Isto foi para uma auditoria, já que a empresa de pentest sugeriu várias medidas de segurança em relação ao registro. O cronjob que configuramos é executado na inicialização:
#!/bin/bash
setfacl -Rm u::rwx,g::r--,o::--- /var/log
find /var/log -type f -exec chmod g-wx,o-rwx "{}" + -o -type d -exec chmod g-w,o-rwx "{}" +
chmod g+wx /var/log
chown -R www-data:adm /var/log/nginx
Aqui estão as permissões de diretórios e arquivos relevantes após executar o cronjob:
O próprio diretório /var/log:
drwxrwx--- 14 root syslog 4096 Aug 27 10:01 log
O próprio diretório /var/log/nginx:
drwxr----- 2 www-data adm 4096 Aug 24 02:25 nginx
E o conteúdo de /var/log/nginx (usamos logs nomeados personalizados em nossa configuração nginx):
-rwxr----- 1 www-data adm 0 Aug 24 02:24 access.log
-rwxr----- 1 www-data adm 108 Aug 24 02:24 error.log
-rwxr----- 1 www-data adm 49317 Aug 27 10:11 x3nr0s.access.log
-rwxr----- 1 www-data adm 798 Aug 27 10:02 x3nr0s.error.log
Se executarmos logrotate --force /etc/logrotate.d/nginx -v(detalhadamente), ou mesmo um manual touchpara criar novos arquivos, eles serão criados com 640 permissões (conforme arquivo de configuração do logrotate). Pelo que li, 640 é suficiente:
-rwxr----- 1 www-data adm 0 Aug 24 02:24 access.log
-rw-r----- 1 www-data adm 0 Aug 27 10:13 error.log
-rwxr----- 1 www-data adm 1972 Aug 27 10:13 error.log.1
-rw-r----- 1 www-data adm 0 Aug 27 10:13 x3nr0s.access.log
-rwxr----- 1 www-data adm 51521 Aug 27 10:13 x3nr0s.access.log.1
-rw-r----- 1 www-data adm 0 Aug 27 10:13 x3nr0s.error.log
-rwxr----- 1 www-data adm 798 Aug 27 10:02 x3nr0s.error.log.1
Como você pode ver, os novos arquivos permanecem vazios e o registro continua no arquivo antigo. Também verifiquei a saída detalhada do logrotate e tudo parece estar funcionando bem em relação à seção postrotate. (Que executa invoke-rc.d nginx rotate. Como mencionei anteriormente, este comando não parece girar nada...)
Como último teste, tentei dar permissões de execução ao usuário para os novos arquivos e fiz um arquivo service nginx rotate. Ainda assim, o nginx usa os arquivos antigos. Algumas outras respostas mencionam para verificar se o espaço em disco está cheio. Não é.
Agradeceríamos ajuda com isso! Obrigado.
Mais informações
Aqui está minha configuração /etc/logrotate.d/nginx:
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi \
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
}
Como mencionado acima, a única maneira de fazer com que o logrotate e o nginx funcionem corretamente com os novos arquivos de log é substituindo a postrotateseção por service nginx reload.
Aqui está a saída de ps -ef | grep nginx:
root 1367 1 0 10:45 ? 00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 1368 1367 0 10:45 ? 00:00:00 nginx: worker process
www-data 1369 1367 0 10:45 ? 00:00:00 nginx: worker process
www-data 1370 1367 0 10:45 ? 00:00:00 nginx: worker process
www-data 1371 1367 0 10:45 ? 00:00:00 nginx: worker process
root 15247 14835 0 11:19 pts/0 00:00:00 grep --color=auto nginx
Aqui está o getfacl/var/log:
# file: var/log
# owner: root
# group: syslog
user::rwx
group::rwx
other::---
E aqui está o getfacl/var/log/nginx:
# file: var/log/nginx
# owner: www-data
# group: adm
user::rwx
group::r--
other::---
Responder1
O /etc/logrotate.d/nginxé o padrão e deve funcionar.
No entanto, alterando o postrotate.dcomando, para forçar o nginx a recarregar sua configuração (e usar o novo arquivo de log)
service nginx reload >/dev/null 2>&1
pode ser uma solução rápida.
Freqüentemente, quando um serviço normalmente funcional não consegue criar/abrir/renomear/alterar um arquivo, direitos de acesso estão envolvidos.
Aqui os acessos foram alterados (por questão de segurança), mas a acl padrão deveria estar funcionando/segura também, sem envolver setfaclo que é poderoso, mas não aparece imediatamente ao usar as lsopções padrão.
A acl padrão é, por/var/log
drwxrwxr-x 18 root syslog 4096 Aug 27 07:25 /var/log/
e o nginx padrão (na verdade) é
drwxr-x--- 2 www-data adm 4096 Aug 27 07:25 /var/log/nginx/
nginxestá bom, /var/logpoderia ser um pouco mais apertado
drwxrwx--x 18 root syslog 4096 Aug 27 07:25 /var/log/
que permitem othersvisitar o diretório (e abaixo), mas impedem que listem o conteúdo.
Quanto ao facl, o getfaclcomando listará quais são as ACLs reais adicionadas para /var/loge /var/log/nginxque /var/log/nginx/*podem revelar um problema.
Aliás, faça também um
dpkg-statoverride --list
para verificar quais ACLs o instalador definirá após uma atualização ou instalação e talvez alterar ou adicionar uma linha, se necessário (man dpkg-statoverride)