Nginx-Dienststeuerung: Ein praktischer Leitfaden für gängige Verwaltungsbefehle

Die Nginx-Dienststeuerung ist nicht kompliziert, aber der Unterschied zwischen reload, restart, stop und nginx -s quit ist wichtig, wenn echte Benutzer verbunden sind. Die sicherste Gewohnheit ist einfach: Testen Sie zuerst die Konfiguration, laden Sie neu, wenn ein sanftes Neuladen ausreicht, und starten Sie nur neu, wenn Sie tatsächlich einen vollständigen Dienstzyklus benötigen.

Die meisten Linux-Server verwenden heute systemd, daher ist systemctl der Befehl, den Sie am häufigsten verwenden werden. Ältere Distributionen verwenden möglicherweise noch den Befehl service. Das Nginx-Binärprogramm akzeptiert auch direkte Signale, die nützlich sind, wenn Sie die Konfiguration neu laden oder Protokolle ohne den Dienstmanager wieder öffnen müssen.

Grundlegendes zur Nginx-Dienstverwaltung

Nginx-Dienstverwaltungsbefehle werden normalerweise mit Systemdienstprogrammen wie systemctl (für Systeme mit systemd, üblich in modernen Linux-Distributionen) oder service (für ältere Init-Systeme) ausgeführt. Der genaue Befehl kann je nach Betriebssystem und dessen Dienstverwaltungsframework leicht variieren.

Nginx starten

Um den Nginx-Webserver zu starten, verwenden Sie den Befehl start. Dieser Befehl initiiert den Nginx-Prozess und macht ihn bereit, eingehende Verbindungen zu akzeptieren.

• Verwendung von systemctl (Empfohlen für moderne Systeme):

  sudo systemctl start nginx
  

• Verwendung von service (Für ältere Systeme):

  sudo service nginx start
  

Wenn Nginx startet, liest es seine Konfigurationsdateien und beginnt, auf den in seiner Konfiguration angegebenen Ports zu lauschen (üblicherweise Port 80 für HTTP und 443 für HTTPS).

Nginx stoppen

Um den Nginx-Webserver ordnungsgemäß herunterzufahren, verwenden Sie den Befehl stop. Dieser Befehl signalisiert Nginx, keine neuen Verbindungen mehr anzunehmen, und ermöglicht es bestehenden Verbindungen, abzuschließen, bevor es beendet wird.

• Verwendung von systemctl:

  sudo systemctl stop nginx
  

• Verwendung von service:

  sudo service nginx stop
  

Auf systemd-Systemen fordert stop den Dienstmanager auf, Nginx zu stoppen. Ob aktive Anfragen Zeit haben, abgeschlossen zu werden, hängt von der Dienstkonfiguration und dem Signalverhalten ab. Wenn Sie speziell ein ordnungsgemäßes Herunterfahren auf Nginx-Ebene benötigen, ist sudo nginx -s quit der direkte Befehl, den Sie kennen sollten.

Nginx neu starten

Der Befehl restart ist eine Kombination aus stop gefolgt von start. Er wird oft nach wesentlichen Konfigurationsänderungen verwendet, die einen vollständigen Dienstzyklus erfordern, um wirksam zu werden. Verwenden Sie diesen Befehl mit Vorsicht, da er den Dienst kurzzeitig unterbricht.

• Verwendung von systemctl:

  sudo systemctl restart nginx
  

• Verwendung von service:

  sudo service nginx restart
  

Dies ist ein üblicher Befehl zum Anwenden bestimmter Arten von Konfigurationsaktualisierungen.

Nginx neu laden

Der Befehl reload ist einer der nützlichsten Nginx-Befehle zum Anwenden von Konfigurationsänderungen, ohne aktive Verbindungen zu trennen. Nginx startet seine Worker-Prozesse ordnungsgemäß neu, sodass sie die neue Konfiguration übernehmen können. Dies ist die bevorzugte Methode für die meisten Konfigurationsaktualisierungen.

• Verwendung von systemctl:

  sudo systemctl reload nginx
  

• Verwendung von service:

  sudo service nginx reload
  

Tipp: Versuchen Sie nach Möglichkeit immer, reload anstelle von restart zu verwenden, um Ausfallzeiten zu minimieren.

Wenn ein Neuladen fehlschlägt, weil die neue Konfiguration ungültig ist, laufen die alten Worker-Prozesse normalerweise mit der alten Konfiguration weiter. Das ist ein Grund, warum Neuladen bei routinemäßigen Bearbeitungen sicherer ist als Neustarten. Führen Sie dennoch immer zuerst nginx -t aus, damit Sie sich bei einem Vorfall nicht auf das Fehlverhalten verlassen müssen.

Nginx-Status prüfen

Um zu überprüfen, ob Nginx läuft, ob es fehlgeschlagen ist oder um seinen aktuellen Zustand zu verstehen, verwenden Sie den Befehl status.

• Verwendung von systemctl:

  sudo systemctl status nginx
  

• Verwendung von service:

  sudo service nginx status
  

Dieser Befehl liefert wertvolle Informationen, einschließlich der Frage, ob der Dienst aktiv ist, seine Prozess-ID (PID) und aktuelle Protokolleinträge, die für eine schnelle Diagnose hilfreich sein können.

Testen der Nginx-Konfiguration

Bevor Sie Konfigurationsänderungen anwenden, insbesondere nach einem restart oder reload, ist es entscheidend, Ihre Konfigurationsdateien auf Syntaxfehler zu testen. Nginx bietet einen integrierten Befehl für diesen Zweck.

Konfigurationssyntax testen

Dieser Befehl überprüft die gesamte Nginx-Konfiguration auf Syntaxfehler, ohne die Änderungen tatsächlich anzuwenden. Er meldet alle gefundenen Probleme.

nginx -t

Beispielausgabe (Erfolg):

test is successful
nginx: configuration file /etc/nginx/nginx.conf test is successful

Beispielausgabe (Fehler):

nginx: [emerg] unknown directive "server_name " in /etc/nginx/sites-available/default:10
nginx: configuration file /etc/nginx/nginx.conf test failed

Warnung: Führen Sie nach dem Ändern einer Konfigurationsdatei und vor dem Neuladen oder Neustarten von Nginx immer nginx -t aus. Dieser einfache Schritt kann unerwartete Ausfallzeiten aufgrund von Syntaxfehlern verhindern.

Wenn Ihre Konfiguration eine benutzerdefinierte Hauptkonfigurationsdatei verwendet, übergeben Sie sie explizit:

sudo nginx -t -c /pfad/zu/nginx.conf

Um die vollständig geladene Konfiguration einschließlich eingebundener Dateien anzuzeigen, verwenden Sie:

sudo nginx -T

Seien Sie vorsichtig mit nginx -T in gemeinsam genutzten Terminals oder Tickets, da es sensible Pfade, Upstream-Namen oder Kommentare aus Konfigurationsdateien ausgeben kann.

Nginx beim Booten aktivieren

Nginx einmal zu starten ist etwas anderes, als es nach einem Neustart zu aktivieren. Verwenden Sie auf systemd-Systemen:

sudo systemctl enable nginx

Um es zu aktivieren und sofort zu starten:

sudo systemctl enable --now nginx

Um zu verhindern, dass es beim Booten automatisch startet:

sudo systemctl disable nginx

Dies ist nach einer Paketinstallation nützlich. Ich habe schon viele Server gesehen, auf denen Nginx während der Einrichtung manuell gestartet wurde, wochenlang einwandfrei funktionierte und dann nach einem Wartungsneustart ausfiel, weil niemand den Dienst aktiviert hatte.

Überprüfen von Protokollen nach Dienstaktionen

Starren Sie nach einem fehlgeschlagenen Start oder Neuladen nicht auf die Eingabeaufforderung. Fragen Sie systemd und Nginx, was passiert ist:

sudo journalctl -u nginx -n 100 --no-pager

Und überprüfen Sie das Nginx-Fehlerprotokoll:

sudo tail -n 100 /var/log/nginx/error.log

Häufige Meldungen sind direkt genug, wenn Sie wissen, wonach Sie suchen müssen:

• bind() to 0.0.0.0:80 failed: Ein anderer Prozess verwendet möglicherweise bereits den Port oder die Berechtigungen sind falsch.
• unknown directive: Ein Tippfehler, fehlendes Modul oder eine Direktive, die in der falschen Nginx-Build-Version verwendet wird.
• host not found in upstream: DNS fehlgeschlagen oder der Upstream-Name ist falsch.
• permission denied: Nginx kann eine Datei nicht lesen, Protokolle nicht schreiben oder auf einen Zertifikatsschlüssel nicht zugreifen.

Bei Portkonflikten gibt dies normalerweise die Antwort:

sudo ss -ltnp | grep -E ':80|:443'

Wenn ein anderer Webserver auf demselben Port lauscht, entscheiden Sie, welcher Dienst ihn besitzen soll. Töten Sie den Prozess nicht einfach, es sei denn, Sie wissen, warum er da ist.

Neuladen versus Neustarten in realen Situationen

Verwenden Sie reload nach den meisten Konfigurationsbearbeitungen: neue Serverblöcke, geänderte Proxy-Header, aktualisierte Timeout-Werte, neue Weiterleitungen, geänderte Protokollformate oder angepasste statische Dateispeicherorte. Nginx startet neue Worker mit der neuen Konfiguration und lässt alte Worker die vorhandene Arbeit beenden.

Verwenden Sie restart, wenn der Dienst selbst einen sauberen Start benötigt. Beispiele sind geänderte systemd-Limits, geänderte Umgebungen, die vom Dienst geerbt werden, Paket-Upgrades, bei denen sich das Binärprogramm geändert hat, oder Situationen, in denen der Master-Prozess fehlerhaft ist. Ein Neustart kann den Datenverkehr kurzzeitig unterbrechen, also führen Sie ihn absichtlich durch.

Verwenden Sie stop, wenn Sie den Dienst herunterfahren möchten. Das klingt offensichtlich, ist aber während der Wartung wichtig. Wenn ein Load Balancer nach dem Stoppen von Nginx immer noch Datenverkehr an einen Server sendet, sehen Benutzer Fehler. Entfernen Sie den Server nach Möglichkeit zuerst aus dem Load Balancer.

Verwenden Sie nginx -s reopen nach manueller Protokollrotation, wenn Ihr Rotationsprozess Nginx nicht bereits signalisiert. Ohne erneutes Öffnen schreibt Nginx möglicherweise weiterhin in den alten Datei-Handle, selbst nachdem die sichtbare Protokolldatei verschoben wurde.

Paketnamen und Dienstnamen

Die meisten Distributionen nennen den Dienst nginx, aber nicht jede Umgebung ist identisch. Wenn systemctl status nginx besagt, dass die Einheit nicht existiert, listen Sie passende Einheiten auf:

systemctl list-unit-files | grep -i nginx

Auf einigen Hosts kann Nginx aus einem benutzerdefinierten Paket, einem Container, einem Control Panel oder einem gebündelten Stack installiert sein. In diesen Fällen steuern systemd-Befehle möglicherweise nicht die Instanz, die Sie tatsächlich verwenden. Bestätigen Sie das Binärprogramm und den Konfigurationspfad:

which nginx
nginx -V

nginx -V gibt Build-Optionen und Modulpfade aus. Es ist auch hilfreich, wenn eine Konfigurationsdirektive auf einem Server funktioniert, auf einem anderen jedoch fehlschlägt, weil das Modul fehlt.

Wenn Nginx in Docker läuft, sind Dienstbefehle auf dem Host möglicherweise irrelevant. Sie würden stattdessen durch den Container-Workflow inspizieren und neu laden:

docker ps
docker exec <container> nginx -t
docker exec <container> nginx -s reload

Verwenden Sie das Orchestrierungstool, das den Prozess besitzt. Für Kubernetes bedeutet das normalerweise, eine ConfigMap oder Ingress-Ressource zu ändern und den Controller neu laden zu lassen, nicht in einen Pod zu shellen, um eine dauerhafte Lösung zu finden.

Ein paar Befehlssequenzen für den Ernstfall

Wenn eine Konfigurationsänderung das Neuladen unterbricht:

sudo nginx -t
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log

Beheben Sie den ersten Syntax- oder Dateifehler, der von nginx -t angezeigt wird, und testen Sie dann erneut. Starten Sie den Dienst nicht neu, um "zu sehen, ob es funktioniert", wenn der Syntax-Test bereits sagt, dass dies nicht der Fall sein wird.

Wenn die Website ausgefallen ist und Sie nicht sicher sind, ob Nginx läuft:

sudo systemctl status nginx
sudo ss -ltnp | grep -E ':80|:443'
curl -I http://127.0.0.1/

Dies trennt drei Fragen: Ist der Dienst aktiv, lauscht etwas auf den erwarteten Ports und funktioniert eine lokale HTTP-Anfrage? Wenn lokales curl funktioniert, die öffentliche Website jedoch ausfällt, überprüfen Sie DNS, Firewall-Regeln, Cloud-Sicherheitsgruppen, Load Balancer oder TLS.

Wenn HTTPS nach der Zertifikatserneuerung fehlschlägt:

sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager

Zertifikatspfadfehler erscheinen normalerweise im Syntax-Test oder Fehlerprotokoll. Berechtigungsprobleme sind ebenfalls häufig, wenn der Zertifikatsschlüssel für root lesbar ist, der Nginx-Worker-Benutzer jedoch nicht auf das erforderliche Verzeichnis zugreifen kann. Seien Sie vorsichtig mit Berechtigungen für private Schlüssel; machen Sie sie nicht weltweit lesbar, nur um einen Fehler zu unterdrücken.

Wenn Protokolle nach der Rotation nicht mehr aktualisiert werden:

sudo nginx -s reopen
sudo ls -l /var/log/nginx/
sudo tail -f /var/log/nginx/access.log

Viele logrotate-Pakete kümmern sich bereits darum. Der Befehl ist dennoch nützlich, wenn Sie Protokolle manuell rotieren oder ein benutzerdefiniertes Protokollierungssetup ausführen.

Was Sie nicht tun sollten

Führen Sie kill -9 nicht als normale Verwaltungsmethode gegen Nginx-Worker-Prozesse aus. Es gibt dem Prozess keine Chance, die Arbeit zu beenden oder aufzuräumen. Verwenden Sie systemctl stop, systemctl restart oder die Nginx-Signal-Befehle, es sei denn, Sie haben es mit einem wirklich feststeckenden Prozess zu tun und verstehen die Nebenwirkungen.

Bearbeiten Sie keine Dateien in sites-available und gehen Sie davon aus, dass sie aktiv sind. Bei Debian-ähnlichen Layouts benötigt eine Site normalerweise einen Symlink in sites-enabled. Bei anderen Distributionen verwendet das Layout möglicherweise conf.d. nginx -T ist der schnellste Weg, um zu sehen, was Nginx tatsächlich lädt.

Vergessen Sie nicht sudo. Die Ausführung von nginx -t als unprivilegierter Benutzer kann fehlschlagen, weil er keine Zertifikatsschlüssel oder eingebundenen Dateien lesen kann, selbst wenn der Dienst selbst dies kann. Testen Sie so, wie der Dienst in der Produktion ausgeführt wird:

sudo nginx -t

Verwenden Sie Neustart nicht als Reflex. Neustart hat seine Berechtigung, ist aber schwerer als Neuladen. Während eines ruhigen Wartungsfensters spielt das vielleicht keine Rolle. Während eines geschäftigen Verkaufsevents schon.

Verwalten von Nginx-Prozessen (Fortgeschritten)

Während systemctl und service die primären Werkzeuge zur Verwaltung des gesamten Nginx-Dienstes sind, können Sie auch direkt mit dem Nginx-Master-Prozess interagieren, indem Sie den Befehl nginx mit bestimmten Signalen verwenden.

Senden von Signalen an Nginx

Nginx verwendet einen Master-Prozess, der Worker-Prozesse verwaltet. Sie können Signale an den Master-Prozess senden, um sein Verhalten zu beeinflussen. Der gebräuchlichste Weg, dies zu tun, besteht darin, die PID des Master-Prozesses zu finden und den Befehl kill zu verwenden, oder bequemer, indem Sie nginx -s <signal> verwenden.

• Konfiguration neu laden: Ähnlich wie der Befehl reload oben.

  sudo nginx -s reload
  

• Ordentliches Herunterfahren: Ähnlich wie der Befehl stop.

  sudo nginx -s quit
  

• Schnelles Herunterfahren: Dies beendet alle Worker-Prozesse sofort, ohne darauf zu warten, dass aktuelle Anfragen bedient werden.

  sudo nginx -s stop
  

• Protokolldateien erneut öffnen: Nützlich, wenn Sie Protokolldateien manuell rotieren oder wenn Protokolle an einen anderen Speicherort geschrieben werden.

  sudo nginx -s reopen
  

Um nginx -s <signal> zu verwenden, muss Nginx wissen, wo sich die PID-Datei seines Master-Prozesses befindet. Standardmäßig ist dies oft /var/run/nginx.pid oder /run/nginx.pid. Sie können bei Bedarf einen anderen PID-Dateispeicherort mit der Option -c angeben, aber dies ist für Standardinstallationen selten erforderlich.

Ein sicherer täglicher Arbeitsablauf

Verwenden Sie für normale Konfigurationsbearbeitungen diesen Arbeitsablauf:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx

Überprüfen Sie dann die Site von einem Client aus:

curl -I https://example.com/

Wenn der Dienst nicht startet, führen Sie nicht wiederholt Neustarts durch. Lesen Sie die Statusausgabe und Protokolle, beheben Sie den ersten echten Fehler, testen Sie erneut und starten oder laden Sie dann neu. Nginx-Dienststeuerungsbefehle sind klein, aber in der richtigen Reihenfolge verwendet, verhindern sie, dass eine schlechte Konfigurationsbearbeitung zu vermeidbaren Ausfallzeiten wird.