J'utilise nginx comme proxy inverse. Chaque fois que je mets à jour la configuration de ce dernier en utilisant
sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"Je dois faire face à une brève indisponibilité. Comment puis-je l'éviter ?
Exécuter service nginx reload o /etc/init.d/nginx reload
Il effectuera un rechargement à chaud de la configuration sans temps d'arrêt. Si vous avez des requêtes en attente, il y aura des processus nginx persistants qui traiteront ces connexions avant que le serveur ne meure, c'est donc une façon extrêmement gracieuse de recharger les configurations.
Parfois, vous voudrez peut-être faire précéder le texte de sudo
Les deux devraient faire exactement ce que la question demande : envoyer SIGHUP au processus maître de nginx. Il ne devrait pas y avoir de différence. nginx.org/fr/docs/control.html
Lorsque je lance la commande sur CentOS, il continue à dire "Usage /etc/init.d/nginx (start..stop..restart..reload)" ... et c'est exactement la façon dont je l'ai utilisé. Dans le fichier /init.d/nginx, j'ai trouvé kill -HUP cat $PIDFILE || echo -n " can't reload " (Impossible de recharger)
Savez-vous quelle est la différence entre service nginx reload y nginx -s reload ? Si j'exécute le premier, j'obtiens ce résultat : Reloading nginx configuration: nginx. mais mes modifications ne sont pas mises à jour. Si j'exécute cette dernière, je n'obtiens aucun résultat, mais mes modifications sont prises en compte.
Exécuter /usr/sbin/nginx -s reload
Ver http://wiki.nginx.org/CommandLine pour plus d'options de ligne de commande.
C'est une meilleure solution. Parce que votre serveur n'a pas en bas si vos configurations comportent des erreurs (dans ce cas, il ne s'agit que de montrer les erreurs).
Non, vous avez tort, vous n'êtes pas censé faire face à un temps d'arrêt avec la procédure que vous décrivez. (Nginx peut faire non seulement le rechargement de la configuration à la volée sans aucun temps d'arrêt, mais même la mise à niveau de l'exécutable à la volée, toujours sans aucun temps d'arrêt).
Conformément à http://nginx.org/docs/control.html#reconfiguration en envoyant le HUP à nginx permet de s'assurer qu'il effectue un redémarrage en douceur, et, si les fichiers de configuration sont incorrects, toute la procédure est abandonnée, et vous vous retrouvez avec le nginx tel qu'il était avant l'envoi du signal HUP signal. À aucun moment, un temps d'arrêt ne doit être possible.
Pour que nginx puisse relire le fichier de configuration, un signal HUP doit être envoyé au processus maître. Le processus maître vérifie d'abord la validité de la syntaxe, puis tente d'appliquer la nouvelle configuration, c'est-à-dire d'ouvrir les fichiers journaux et les nouvelles sockets d'écoute. En cas d'échec, il annule les modifications et continue à travailler avec l'ancienne configuration.
En général, le rechargement du fichier de configuration d'un service ne devrait pas affecter le service en cours d'exécution. Cependant, cela dépend de la façon dont le SIGHUP est traité.
Si un service spécifique subit un temps d'arrêt pendant le rechargement, on peut contourner ce problème en exécutant le même service sur plusieurs serveurs, de préférence en utilisant un équilibreur de charge. Dans ce cas, vous pouvez retirer un serveur à la fois et le recharger/redémarrer. Vous pouvez ensuite le réintégrer après avoir vérifié que tout va bien.
Bien que cela ne réponde pas directement à la question, il s'agit certainement d'un scénario de meilleure pratique que le PO serait bien inspiré de suivre pour éviter les temps d'arrêt en général.
Détails sur la façon dont nginx traite les différents signaux : nginx.org/fr/docs/control.html
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
S'agit-il de commandes en ligne de commande ? Je n'ai jamais vu personne mettre une commande sudo entière entre guillemets comme ça, ce n'est peut-être pas nécessaire.
5 votes
Juste un commentaire général : Je pense que la pratique standard/recommandée consiste à créer un lien souple/symbolique pour la configuration de votre site sous la rubrique
sites-enabledet non le copier. Cela n'a rien à voir avec votre problème particulier, mais vous pouvez y réfléchir.2 votes
Vous ne devriez pas être confronté à un temps d'arrêt.
kill HUPest la façon de faire un rechargement en douceur dans nginx.