Nginx config recharger sans temps d'arrêt

123

J'utilise nginx en tant que proxy inverse. Chaque fois que je mets à jour la configuration pour elle en utilisant

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"

Je fais face à un bref temps d'arrêt. Comment puis-je éviter cela?

nginx

— Saurav Shah
source

1

S'agit-il de commandes en ligne de commande? Je n'ai jamais vu personne mettre une commande sudo entière entre guillemets, ce n'est peut-être pas nécessaire.

— brianmearns

4

Juste un commentaire général: Je pense que la pratique standard / recommandée est de créer un lien symbolique pour la configuration de votre site sous sites-enabled, pas de le copier. Pas lié à votre problème particulier, mais vous voudrez peut-être examiner cela.

— brianmearns

1

Vous ne devriez pas être confronté à un temps d'arrêt. kill HUPest le moyen de faire un rechargement gracieux dans nginx.

— Jonathan Vanasco

180

Courir service nginx reloadou/etc/init.d/nginx reload

Il effectuera un rechargement à chaud de la configuration sans temps d'arrêt. Si vous avez des demandes en attente, il y aura des processus nginx en attente qui gèreront ces connexions avant sa mort. Il s'agit donc d'un moyen extrêmement élégant de recharger les configurations.

Parfois, vous voudrez peut-être préfixer avec sudo

— Hengjie
source

10

Les deux doivent faire exactement ce que dit la question: envoyer SIGHUPau processus maître nginx. Il ne devrait pas y avoir de différence. nginx.org/en/docs/control.html

— Gnarfoz

Quand je lance la commande sur CentOS, il continue de dire "Utilisation /etc/init.d/nginx (start..stop ... restart..reload)" .. et c'est exactement comme je l'ai utilisé. Dans le fichier /init.d/nginx j'ai trouvé kill -HUP cat $PIDFILE|| echo -n "ne peut pas recharger"

— mashup

1

Savez-vous quelle est la différence entre service nginx reloadet nginx -s reload? Si je lance l'ancien, j'obtiens le résultat suivant:, Reloading nginx configuration: nginx.mais mes modifications ne sont pas mises à jour. Si je lance ce dernier, je n'obtiens aucune sortie, mais mes modifications sont reflétées.

— Ryan Quinn

Je viens d'essayer cela après avoir ajouté une log_not_founddirective, mais j'ai constaté que je devais faire un redémarrage pour que cela fonctionne. Je suppose que le rechargement ne fonctionne pas pour toutes les directives?

— mydoghasworms

81

Courir /usr/sbin/nginx -s reload

Voir http://wiki.nginx.org/CommandLine pour plus d'options en ligne de commande.

— Shiv Kumar Sah
source

Enfin, une commande qui fonctionne dans Debian Jessie.

— danger89

1

C'est un meilleur moyen. Parce que votre serveur n'est pas en panne si vos configurations comportent des erreurs (ne montre que les erreurs dans ce cas).

— Mir-Ismaili

si nginx pid par défaut ne se trouve pas à l'emplacement par défaut, vous devez indiquer '-p'. c'est-à-dire: `/ opt / gitlab / embedded / sbin / nginx -s reload -p / var / opt / gitlab / nginx`

— qxo le

9

Non, vous avez tort, vous n'êtes pas censé faire face à un temps mort avec la procédure que vous décrivez. (Nginx peut non seulement recharger la configuration à la volée sans interruption, mais même mettre à niveau l'exécutable à la volée, toujours sans interruption.)

Conformément à http://nginx.org/docs/control.html#reconfiguration , l'envoi du HUPsignal à nginx garantit son redémarrage en douceur et, si les fichiers de configuration sont incorrects, toute la procédure est abandonnée et vous ' re avec le nginx comme avant d’envoyer le HUPsignal. Aucun temps d'arrêt ne devrait être possible.

Pour que nginx puisse relire le fichier de configuration, un signal HUP doit être envoyé au processus maître. Le processus principal vérifie d'abord la validité de la syntaxe, puis essaie d'appliquer une nouvelle configuration, c'est-à-dire d'ouvrir des fichiers journaux et de nouveaux sockets d'écoute. Si cela échoue, il annule les modifications et continue à fonctionner avec l'ancienne configuration.

— cnst
source

2

Habituellement, 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 SIGHUPsignal est traité.

Si un service spécifique connaît un temps d'arrêt pendant le rechargement, vous pouvez le contourner en exécutant le même service sur plusieurs serveurs, de préférence à l'aide d'un équilibreur de charge. Dans ce cas, vous pouvez retirer un serveur à la fois et le recharger / le redémarrer. Ensuite, il peut être rajouté après confirmation que tout va bien.

— Khaled
source

Bien que cela ne réponde pas directement à la question, il s'agit certainement d'un scénario fondé sur les meilleures pratiques que le PO serait intelligent pour suivre afin d'éviter les temps d'arrêt en général.

— Andrew M.

1

Détails sur la façon dont nginx gère les différents signaux: nginx.org/fr/docs/control.html

— Gnarfoz