Ich habe Probleme mit allen Befehlen, die nginx anweisen, neue Protokolldateien zu verwenden. Ich verwende Ubuntu 18.04, nginx/1.14.0, logrotate 3.11.0
Wenn ich neue access.log
oder error.log
Dateien in /var/log/nginx erstelle, entweder manuell oder über logrotate, werden sie nicht verwendet und stattdessen nutzt der Dienst die alten Protokolldateien (die ich access.log.1
für diesen Test umbenannt habe, um zu simulieren, was logrotate macht).
Ich habe die folgenden Befehle (getrennt) ausprobiert. Keiner von ihnen erzeugt eine Fehlermeldung, sie erzeugen alle die erwartete Ausgabe. Aber nginx weigert sich, die Verwendung der alten Protokolle einzustellen.
service nginx rotate
invoke-rc.d nginx rotate
kill -USR1 `cat /var/run/nginx.pid`
Ich habe auch überprüft, ob sich die obige .pid
Datei am richtigen Ort befindet.
Die einzige Möglichkeit, wie ich die Protokollrotation zum Laufen bringen konnte, ist über einen service nginx reload
, der die Aufgabe erledigt, aber auch Konfigurationsdateien neu lädt. Ich weiß, dass es bei einem Neuladen keine Ausfallzeiten gibt, aber ich würde es trotzdem vorziehen, so wenig wie möglich neu zu laden, weshalb ich es zum service nginx rotate
Laufen bringen möchte.
Ich bin fast sicher, dass es an Berechtigungsproblemen in liegt /var/log
. Vor Kurzem haben wir einen Cronjob eingerichtet, um sicherzustellen, dass die Protokolldateien sichere Berechtigungen haben. Dies war für ein Audit, da das Pentest-Unternehmen verschiedene Sicherheitsmaßnahmen in Bezug auf die Protokollierung vorgeschlagen hatte. Der von uns eingerichtete Cronjob wird beim Booten ausgeführt:
#!/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
Hier sind die Berechtigungen der relevanten Verzeichnisse und Dateien nach dem Ausführen des Cronjobs:
Das Verzeichnis /var/log selbst:
drwxrwx--- 14 root syslog 4096 Aug 27 10:01 log
Das Verzeichnis /var/log/nginx selbst:
drwxr----- 2 www-data adm 4096 Aug 24 02:25 nginx
Und der Inhalt von /var/log/nginx (wir verwenden benutzerdefinierte benannte Protokolle in unserer Nginx-Konfiguration):
-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
Wenn wir logrotate --force /etc/logrotate.d/nginx -v
(ausführlich) oder sogar manuell touch
neue Dateien erstellen, werden diese mit 640 Berechtigungen erstellt (gemäß der Konfigurationsdatei von logrotate). Soweit ich gelesen habe, reichen 640:
-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
Wie Sie sehen, bleiben die neuen Dateien leer und die Protokollierung wird in der alten Datei fortgesetzt. Ich habe auch die ausführliche Logrotate-Ausgabe überprüft und im Hinblick auf den Postrotate-Abschnitt scheint alles in Ordnung zu sein. (Der ausgeführt wird invoke-rc.d nginx rotate
. Wie ich bereits erwähnt habe, scheint dieser Befehl nichts zu rotieren...)
Als letzten Test habe ich versucht, dem Benutzer Ausführungsberechtigungen für die neuen Dateien zu erteilen, und habe einen ausgeführt service nginx rotate
. Nginx verwendet immer noch die alten Dateien. In einigen anderen Antworten wird erwähnt, dass geprüft werden soll, ob der Speicherplatz voll ist. Dies ist nicht der Fall.
Würde mich über Hilfe freuen! Danke.
Weitere Informationen
Hier ist meine /etc/logrotate.d/nginx-Konfiguration:
/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
}
Wie oben erwähnt, kann ich logrotate und nginx nur dazu bringen, mit den neuen Protokolldateien ordnungsgemäß zu funktionieren, indem ich den postrotate
Abschnitt durch ersetze service nginx reload
.
Hier ist die Ausgabe von 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
Hier ist das getfacl
in /var/log:
# file: var/log
# owner: root
# group: syslog
user::rwx
group::rwx
other::---
Und hier ist das getfacl
zu /var/log/nginx:
# file: var/log/nginx
# owner: www-data
# group: adm
user::rwx
group::r--
other::---
Antwort1
Dies /etc/logrotate.d/nginx
ist die Standardeinstellung und sollte funktionieren.
Ändern Sie jedoch den postrotate.d
Befehl, um nginx zu zwingen, seine Konfiguration neu zu laden (und die neue Protokolldatei zu verwenden).
service nginx reload >/dev/null 2>&1
könnte eine schnelle Lösung sein.
Wenn ein normalerweise funktionierender Dienst eine Datei nicht erstellen/öffnen/umbenennen/ändern kann, sind häufig Zugriffsrechte betroffen.
Hier wurden die Zugriffe (aus Sicherheitsgründen) geändert, aber die Standard-ACL sollte auch funktionieren/sicher sein, ohne dass sie einbezogen wird, setfacl
was zwar leistungsstark ist, aber bei Verwendung der Standardoptionen nicht sofort angezeigt wird ls
.
Die Standard-ACL ist für/var/log
drwxrwxr-x 18 root syslog 4096 Aug 27 07:25 /var/log/
und der Standard-nginx ist (eigentlich)
drwxr-x--- 2 www-data adm 4096 Aug 27 07:25 /var/log/nginx/
nginx
ist ok, /var/log
könnte etwas enger sein
drwxrwx--x 18 root syslog 4096 Aug 27 07:25 /var/log/
die others
den Zugriff auf das Verzeichnis (und darunter) ermöglichen, aber die Auflistung des Inhalts verhindern.
Was die facl betrifft, getfacl
listet der Befehl die tatsächlich hinzugefügten ACLs für /var/log
und /var/log/nginx
auf /var/log/nginx/*
, was auf ein Problem hinweisen könnte.
Machen Sie übrigens auch eine
dpkg-statoverride --list
um zu prüfen, welche ACLs das Installationsprogramm nach einem Update oder einer Installation setzt, und ggf. eine Zeile zu ändern oder hinzuzufügen (man dpkg-statoverride)