it-swarm.com.de

Wie kann ich den Speicherort des Nginx-Fehlerprotokolls deaktivieren oder angeben?

Ich habe den Nginx auf Ubuntu selbst kompiliert. Ich starte mein nginx mit dem Parameter -c nginx.conf. In meiner Datei nginx.conf versuche ich, das Fehlerprotokoll zu deaktivieren, aber es ist fehlgeschlagen.

error_log /dev/null crit;

Immer noch die Fehlermeldung: nginx: [alert] konnte die Fehlerprotokolldatei nicht öffnen: open () "/usr/nginx/logs/error.log" ist fehlgeschlagen (2: Keine solche Datei oder kein solches Verzeichnis)

Wie kann ich dieses Protokoll deaktivieren oder seinen Speicherort ändern?

19
Dean Chen

Die Syntax für das Deaktivieren des Fehlerprotokolls ist in Ordnung, aber der Status docs , dass eine Standardprotokolldatei verwendet wird, bevor die Konfiguration gelesen wird. (was vernünftig erscheint, wie würde es Ihnen sonst sagen, dass Sie einen Fehler in Ihrer Konfiguration haben)

Erstellen Sie diese Datei manuell mit den richtigen Berechtigungen für den Benutzer, der nginx ausführt. Oder starten Sie den Server als root.

17
RickyA

Ich habe dieses Problem mit dem Parameter -p beim Starten von nginx behoben, z. B .:

/home/ubuntu/nginx/sbin/nginx -c /home/ubuntu/nginx/conf/nginx.conf -p /home/ubuntu/nginx

Dadurch werden alle in der config angegebenen Protokollpfade dem Präfixverzeichnis vorangestellt.

15
Michael

Ich habe das Problem mit diesem Konfigurationsparameter gelöst:

./configure --prefix="$HOME/nginx" --error-log-path=/dev/stderr

Da ich diesen nginx nie als Daemon benutze und immer in einer Shell laufe, ist es sinnvoll, Fehler in stderr zu protokollieren.

2
Hubro

Je diesem Beitrag in der nginx.org-Mailingliste (Auszug zitiert unten) wird %%ERROR_LOG_PATH%% als Kompilierungsoption festgelegt und beim Start sofort geprüft, was die Warnung "Konnte nicht öffnen" auslösen. Die Angabe des Präfixes (mit -p) kann dazu beitragen, die Warnung zu unterdrücken, aber nur, wenn %%ERROR_LOG_PATH%% zur Kompilierungszeit als relative Pfad angegeben wurde.

Sie können mit überprüfen, wie es in Ihrer aktuellen ausführbaren Datei angegeben ist

nginx -V 2>&1 | grep -oE 'error-log-path=\S*'

Deshalb funktioniert die von @Michael vorgeschlagene Lösung für einige, nicht aber für andere.

Siehe changelog:

Ändert sich mit nginx 0.7.53

...

*) Änderung: Jetzt wird ein Protokoll, das von --error-log-path festgelegt wurde, vom Start Aus erstellt.

*) Feature: Jetzt werden die Startfehler und Warnungen an Error_log und stderr ausgegeben.

...

Der in error_log kompilierte Wert wird immer zum Protokollieren von Fehlern zum Zeitpunkt Verwendet (und gibt eine Warnung aus, wenn nginx ihn nicht öffnen kann). Nachdem die Konfigurationsdatei Gelesen wurde, wird stattdessen das error_log aus der Konfiguration verwendet.

Wenn Sie nginx mit dem Pfad error_log relativ zum Präfix Kompiliert haben, sollte es möglich sein, den Startfehler error_log über die Option -p Zu überschreiben.

Maxim Dounin

0
Randall

Sie können das Problem nicht lösen, indem Sie ein -p-Präfix angeben. weil das nur für die Direktiven in der Konfigurationsdatei gelten würde; und wie RickyA bereits bemerkt hat, besteht das Problem darin, dass es ein kompiliertes Fehlerprotokoll gibt, das nginx öffnen möchte, noch bevor die Konfiguration geöffnet wird. Das Ändern der Berechtigungen des kompilierten Fehlerprotokolls ist aus naheliegenden Gründen nicht ideal.

Eine Problemumgehung besteht darin, das Fehlerprotokoll als Konfiguration in der Befehlszeile anzugeben:

$ nginx -p . -g 'error_log error.log;'

oder

$ nginx -p . -g 'error_log stderr;'

Sie werden immer noch eine [Warnung] erhalten, aber zumindest konnte ich Nginx als nicht-root auf Ubuntu starten.

0
Ben Hekster

Es ist nicht erforderlich, einen Befehlszeilenparameter zu verwenden. Stellen Sie einfach sicher, dass Sie die Anweisung error_log ganz oben in der Datei nginx.conf oder zumindest vor dem Auftreten von Fehlermeldungen hinzufügen.

der Kommentar von nh2 vom Januar 2016 deutet darauf hin, dass diese Option seit mindestens einigen Jahren verfügbar gewesen wäre. Ich kann bestätigen, dass es funktioniert und es weniger stressig ist. Bei der Anpassung an nginx.conf treten weniger Probleme mit Aktualisierungen einer gepackten nginx-Installation auf als bei den Alternativen.

0
Sam Hall