Contrôle du service Nginx : Guide pratique des commandes de gestion courantes

Le contrôle du service Nginx n'est pas compliqué, mais la différence entre reload, restart, stop et nginx -s quit compte lorsque de vrais utilisateurs sont connectés. L'habitude la plus sûre est simple : tester d'abord la configuration, recharger lorsqu'un rechargement gracieux suffit, et redémarrer uniquement lorsque vous avez réellement besoin d'un cycle de service complet.

La plupart des serveurs Linux utilisent désormais systemd, donc systemctl est la commande que vous utiliserez le plus souvent. Les distributions plus anciennes peuvent encore utiliser la commande service. Le binaire Nginx accepte également des signaux directs, utiles lorsque vous devez recharger la configuration ou rouvrir les journaux sans passer par le gestionnaire de services.

Comprendre la gestion du service Nginx

Les commandes de gestion du service Nginx sont généralement exécutées à l'aide d'utilitaires système comme systemctl (pour les systèmes utilisant systemd, courants dans les distributions Linux modernes) ou service (pour les anciens systèmes init). La commande spécifique peut varier légèrement selon votre système d'exploitation et son cadre de gestion des services.

Démarrer Nginx

Pour lancer le serveur web Nginx, vous utiliserez la commande start. Cette commande initie le processus Nginx, le rendant prêt à accepter les connexions entrantes.

• Avec systemctl (Recommandé pour les systèmes modernes) :

  sudo systemctl start nginx
  

• Avec service (Pour les anciens systèmes) :

  sudo service nginx start
  

Lorsque Nginx démarre, il lit ses fichiers de configuration et commence à écouter sur les ports spécifiés dans sa configuration (généralement le port 80 pour HTTP et 443 pour HTTPS).

Arrêter Nginx

Pour arrêter gracieusement le serveur web Nginx, utilisez la commande stop. Cette commande signale à Nginx de cesser d'accepter de nouvelles connexions et permet aux connexions existantes de se terminer avant de quitter.

• Avec systemctl :

  sudo systemctl stop nginx
  

• Avec service :

  sudo service nginx stop
  

Sur les systèmes systemd, stop demande au gestionnaire de services d'arrêter Nginx. Que les requêtes actives aient le temps de se terminer dépend de la configuration du service et du comportement du signal. Si vous avez spécifiquement besoin d'un arrêt gracieux au niveau de Nginx, sudo nginx -s quit est la commande directe à connaître.

Redémarrer Nginx

La commande restart est une combinaison de stop suivi de start. Elle est souvent utilisée après avoir effectué des modifications importantes de la configuration qui nécessitent un cycle de service complet pour prendre effet. Utilisez cette commande avec prudence car elle interrompt brièvement le service.

• Avec systemctl :

  sudo systemctl restart nginx
  

• Avec service :

  sudo service nginx restart
  

C'est une commande courante pour appliquer certains types de mises à jour de configuration.

Recharger Nginx

La commande reload est l'une des commandes Nginx les plus utiles pour appliquer des modifications de configuration sans interrompre les connexions actives. Nginx redémarre gracieusement ses processus de travail, leur permettant de prendre en compte la nouvelle configuration. C'est la méthode préférée pour la plupart des mises à jour de configuration.

• Avec systemctl :

  sudo systemctl reload nginx
  

• Avec service :

  sudo service nginx reload
  

Astuce : Essayez toujours d'utiliser reload au lieu de restart lorsque c'est possible pour minimiser les temps d'arrêt.

Si un rechargement échoue parce que la nouvelle configuration est invalide, les anciens processus de travail continuent généralement de fonctionner avec l'ancienne configuration. C'est une raison pour laquelle le rechargement est plus sûr que le redémarrage lors des modifications de routine. Néanmoins, exécutez toujours nginx -t d'abord pour ne pas dépendre du comportement d'échec pendant un incident.

Vérifier l'état de Nginx

Pour vérifier si Nginx est en cours d'exécution, s'il a échoué, ou pour comprendre son état actuel, utilisez la commande status.

• Avec systemctl :

  sudo systemctl status nginx
  

• Avec service :

  sudo service nginx status
  

Cette commande fournit des informations précieuses, notamment si le service est actif, son identifiant de processus (PID) et les entrées de journal récentes, ce qui peut être utile pour un diagnostic rapide.

Tester la configuration Nginx

Avant d'appliquer des modifications de configuration, surtout après un restart ou un reload, il est crucial de tester vos fichiers de configuration pour détecter les erreurs de syntaxe. Nginx fournit une commande intégrée à cet effet.

Tester la syntaxe de la configuration

Cette commande vérifie l'ensemble de la configuration Nginx pour les erreurs de syntaxe sans appliquer les modifications. Elle signalera tout problème trouvé.

nginx -t

Exemple de sortie (Succès) :

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

Exemple de sortie (Erreur) :

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

Avertissement : Exécutez toujours nginx -t après avoir modifié un fichier de configuration et avant de recharger ou redémarrer Nginx. Cette étape simple peut éviter des temps d'arrêt imprévus causés par des erreurs de syntaxe.

Si votre configuration utilise un fichier de configuration principal personnalisé, transmettez-le explicitement :

sudo nginx -t -c /path/to/nginx.conf

Pour voir la configuration complète chargée, y compris les fichiers inclus, utilisez :

sudo nginx -T

Soyez prudent avec nginx -T dans des terminaux partagés ou des tickets car il peut afficher des chemins sensibles, des noms d'amont ou des commentaires provenant des fichiers de configuration.

Activer Nginx au démarrage

Démarrer Nginx une fois est différent de l'activer après un redémarrage. Sur les systèmes systemd, utilisez :

sudo systemctl enable nginx

Pour l'activer et le démarrer immédiatement :

sudo systemctl enable --now nginx

Pour l'empêcher de démarrer automatiquement au démarrage :

sudo systemctl disable nginx

Ceci est utile après une installation de paquet. J'ai vu de nombreux serveurs où Nginx a été démarré manuellement lors de l'installation, a parfaitement fonctionné pendant des semaines, puis est resté inactif après un redémarrage de maintenance parce que personne n'avait activé le service.

Vérifier les journaux après les actions de service

Après un démarrage ou un rechargement échoué, ne restez pas à regarder l'invite de commande. Demandez à systemd et Nginx ce qui s'est passé :

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

Et vérifiez le journal des erreurs Nginx :

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

Les messages courants sont assez directs une fois que vous savez quoi chercher :

• bind() to 0.0.0.0:80 failed : un autre processus utilise peut-être déjà le port, ou les permissions sont incorrectes.
• unknown directive : une faute de frappe, un module manquant ou une directive utilisée dans la mauvaise version de Nginx.
• host not found in upstream : DNS a échoué ou le nom d'amont est incorrect.
• permission denied : Nginx ne peut pas lire un fichier, écrire des journaux ou accéder à une clé de certificat.

Pour les conflits de ports, cela donne généralement la réponse :

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

Si un autre serveur web écoute sur le même port, décidez quel service doit le posséder. Ne tuez pas simplement le processus à moins de savoir pourquoi il est là.

Rechargement versus redémarrage dans des situations réelles

Utilisez reload après la plupart des modifications de configuration : nouveaux blocs serveur, en-têtes de proxy modifiés, valeurs de délai d'attente mises à jour, nouvelles redirections, formats de journal modifiés ou emplacements de fichiers statiques ajustés. Nginx démarre de nouveaux workers avec la nouvelle configuration et laisse les anciens workers terminer le travail existant.

Utilisez restart lorsque le service lui-même a besoin d'un démarrage propre. Les exemples incluent les limites systemd modifiées, l'environnement modifié hérité par le service, les mises à niveau de paquets où le binaire a changé, ou les situations où le processus maître est malsain. Le redémarrage peut interrompre brièvement le trafic, alors faites-le intentionnellement.

Utilisez stop lorsque vous voulez que le service soit arrêté. Cela semble évident, mais cela compte pendant la maintenance. Si un équilibreur de charge envoie toujours du trafic vers un serveur après avoir arrêté Nginx, les utilisateurs verront des échecs. Déconnectez d'abord le serveur de l'équilibreur de charge lorsque vous le pouvez.

Utilisez nginx -s reopen après une rotation manuelle des journaux si votre processus de rotation ne signale pas déjà Nginx. Sans réouverture, Nginx peut continuer à écrire sur l'ancien descripteur de fichier même après que le fichier journal visible a été déplacé.

Noms de paquets et noms de services

La plupart des distributions appellent le service nginx, mais tous les environnements ne sont pas identiques. Si systemctl status nginx indique que l'unité n'existe pas, listez les unités correspondantes :

systemctl list-unit-files | grep -i nginx

Sur certains hôtes, Nginx peut être installé à partir d'un paquet personnalisé, d'un conteneur, d'un panneau de contrôle ou d'une pile groupée. Dans ces cas, les commandes systemd peuvent ne pas contrôler l'instance que vous utilisez réellement. Confirmez le binaire et le chemin de configuration :

which nginx
nginx -V

nginx -V affiche les options de construction et les chemins des modules. C'est également utile lorsqu'une directive de configuration fonctionne sur un serveur mais échoue sur un autre parce que le module est manquant.

Si Nginx s'exécute dans Docker, les commandes de service sur l'hôte peuvent être sans importance. Vous inspecteriez et rechargeriez via le workflow du conteneur à la place :

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

Utilisez l'outil d'orchestration qui possède le processus. Pour Kubernetes, cela signifie généralement modifier une ConfigMap ou une ressource Ingress et laisser le contrôleur recharger, plutôt que de se connecter à un pod pour une correction permanente.

Quelques séquences de commandes pour les jours d'incident

Lorsqu'un changement de configuration casse le rechargement :

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

Corrigez la première erreur de syntaxe ou de fichier indiquée par nginx -t, puis testez à nouveau. Ne redémarrez pas le service pour "voir si ça marche" alors que le test de syntaxe dit déjà que ça ne marchera pas.

Lorsque le site est en panne et que vous n'êtes pas sûr que Nginx fonctionne :

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

Cela sépare trois questions : le service est-il actif, quelque chose écoute-t-il sur les ports attendus, et une requête HTTP locale fonctionne-t-elle ? Si curl local fonctionne mais que le site public échoue, vérifiez le DNS, les règles de pare-feu, les groupes de sécurité cloud, les équilibreurs de charge ou TLS.

Lorsque HTTPS échoue après le renouvellement du certificat :

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

Les erreurs de chemin de certificat apparaissent généralement dans le test de syntaxe ou le journal des erreurs. Les problèmes de permission sont également courants si la clé du certificat est lisible par root mais que l'utilisateur du worker Nginx ne peut pas accéder au répertoire requis. Soyez prudent avec les permissions sur les clés privées ; ne les rendez pas lisibles par tout le monde juste pour faire taire une erreur.

Lorsque les journaux cessent de se mettre à jour après la rotation :

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

De nombreux paquets logrotate gèrent déjà cela. La commande est toujours utile lorsque vous faites pivoter les journaux manuellement ou que vous exécutez une configuration de journalisation personnalisée.

Ce qu'il ne faut pas faire

N'exécutez pas kill -9 contre les processus workers Nginx comme méthode de gestion normale. Cela ne donne aucune chance au processus de terminer son travail ou de se nettoyer. Utilisez systemctl stop, systemctl restart ou les commandes de signal Nginx, sauf si vous avez affaire à un processus vraiment bloqué et que vous comprenez les effets secondaires.

Ne modifiez pas les fichiers dans sites-available en supposant qu'ils sont actifs. Sur les dispositions de style Debian, un site a généralement besoin d'un lien symbolique dans sites-enabled. Sur d'autres distributions, la disposition peut utiliser conf.d. nginx -T est le moyen le plus rapide de voir ce que Nginx charge réellement.

N'oubliez pas sudo. Exécuter nginx -t en tant qu'utilisateur non privilégié peut échouer car il ne peut pas lire les clés de certificat ou les fichiers inclus, même si le service lui-même le peut. Testez de la même manière que le service s'exécutera en production :

sudo nginx -t

N'utilisez pas le redémarrage par réflexe. Le redémarrage a sa place, mais il est plus lourd que le rechargement. Pendant une fenêtre de maintenance calme, cela peut ne pas avoir d'importance. Pendant un événement de vente chargé, cela compte.

Gérer les processus Nginx (Avancé)

Bien que systemctl et service soient les outils principaux pour gérer le service Nginx dans son ensemble, vous pouvez également interagir directement avec le processus maître Nginx en utilisant la commande nginx avec des signaux spécifiques.

Envoyer des signaux à Nginx

Nginx utilise un processus maître qui gère les processus workers. Vous pouvez envoyer des signaux au processus maître pour influencer son comportement. La façon la plus courante de le faire est de trouver le PID du processus maître et d'utiliser la commande kill, ou plus commodément, en utilisant nginx -s <signal>.

• Recharger la configuration : Similaire à la commande reload ci-dessus.

  sudo nginx -s reload
  

• Arrêt gracieux : Similaire à la commande stop.

  sudo nginx -s quit
  

• Arrêt rapide : Cela tuera tous les processus workers immédiatement sans attendre que les requêtes en cours soient servies.

  sudo nginx -s stop
  

• Rouvrir les fichiers journaux : Utile si vous faites pivoter les fichiers journaux manuellement ou si les journaux sont écrits à un emplacement différent.

  sudo nginx -s reopen
  

Pour utiliser nginx -s <signal>, Nginx a besoin de savoir où se trouve son fichier PID du processus maître. Par défaut, c'est souvent /var/run/nginx.pid ou /run/nginx.pid. Vous pouvez spécifier un emplacement de fichier PID différent en utilisant l'option -c si nécessaire, mais cela est rarement nécessaire pour les installations standard.

Un flux de travail quotidien sûr

Pour les modifications de configuration normales, utilisez ce flux de travail :

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

Ensuite, vérifiez le site à partir d'un client :

curl -I https://example.com/

Si le service ne démarre pas, n'exécutez pas le redémarrage à plusieurs reprises. Lisez la sortie d'état et les journaux, corrigez la première erreur réelle, testez à nouveau, puis démarrez ou rechargez. Les commandes de contrôle du service Nginx sont petites, mais utilisées dans le bon ordre, elles empêchent une mauvaise modification de configuration de se transformer en temps d'arrêt évitable.