Comment tuer ce travailleur immortel nginx?

J'ai commencé nginx et quand j'ai arrêter comme la racine

/etc/init.d/nginx stop

après que j'type

ps aux | grep nginx

et obtenir de réponse, comme tcp LISTEN 2124 nginx WORKER

kill -9 2124  # tried with kill -QUIT 2124, kill -KILL 2124

et après je tape à nouveau

ps aux | grep nginx

et obtenir de réponse, comme tcp LISTEN 2125 nginx WORKER
et ainsi de suite.

Comment tuer l'immortel Chuck Norris travailleur ?

source d'informationauteur PaolaJ.

  1. 4

    Après kill -9 il n'y a plus rien à faire pour le processus - c'est mort (ou vouée à la mort). La raison pour laquelle il colle autour est parce que soit (un) c'est le processus parent n'a pas attendu pour lui encore, de sorte que le noyau maintient le processus d'entrée de la table pour garder son statut jusqu'à ce que le parent fait, ou (b) le processus est bloqué sur un système d'appel dans le noyau qui n'est pas de finition (ce qui signifie généralement un buggy conducteur et/ou le matériel).

    Si le premier cas, l'obtention du parent d'attendre pour l'enfant, ou de la cessation de la mère, devrait fonctionner. La plupart des programmes n'ont pas une bonne façon de le faire "attendre un enfant", de sorte que ne peut pas être une option.

    Dans le second cas, la solution la plus probable est de redémarrer. Il peut y avoir des outils qui pourraient effacer une telle condition, mais ce n'est pas commun. En fonction de ce que le noyau de traitement, il peut être possible de le faire débloquer par d'autres moyens - mais qui nécessite des connaissances de ce traitement. Par exemple, si le processus est bloqué sur un noyau de verrouillage qu'un autre processus est en quelque sorte la tenue indéfiniment, en terminant, que d'autres processus pourraient aleviate le problème.

    Noter que le ps commande peut distinguer ces deux états. Ces derniers montrent en place dans le 'Z' état. Voir le ps page de manuel pour plus d'info: http://linux.die.net/man/1/ps. Ils peuvent également montrer avec le texte "défunte".

  2. 0

    J'ai eu des problème similaire.

    Vérifier si vous utilisez un auto-guérisseur comme Monit ou le Superviseur qui gère le travailleur à chaque fois que vous essayez de les arrêter. Si Oui, Désactivez-le.

    Ma travailleurs étaient donné naissance à cause des changements que j'oublie que j'ai fait dans update-rc.d dans Ubuntu.

    J'ai donc installé sysv-rc-conf qui donne une interface propre contrôle de ce processus sont au redémarrage, vous pouvez le désactiver à partir de là, et je vous assure pas de Chuck Noris Résurrection 😀

  3. 0

    J'ai eu le même problème.
    Dans mon cas, gitlab a la responsabilité de réunir les nginx travailleurs.
    quand je completelly retiré gitlab à partir de mon serveur, je suis capable de tuer les nginx travailleurs.

    1. ps -aux | grep "nginx"

    2. De recherche pour les travailleurs et vérification lors de la première colonne qui est à les rapprocher.

    3. tuer ou de désinstaller le responsable et de tuer les travailleurs de nouveau, ils cesseront de frai ;D