4 votes

Détruire le service avant de supprimer la relation provoque le blocage des deux services en train de mourir

J'ai déployé wordpress et mysql et ajouté une relation entre wordpress et mysql. J'ai essayé de détruire wordpress avant de supprimer la relation entre wordpress et mysql.

Maintenant, les deux services sont en train de mourir. Que dois-je faire ? Y a-t-il un moyen de supprimer manuellement le service proprement ?

J'utilise Ubuntu 12.04 LTS.

Voici la sortie de juju status mysql :

controller:~$ juju status mysql
environment: maas
machines:
  "0":
    agent-state: started
    agent-version: 1.16.6.1
    dns-name: node-1.master
    instance-id: /MAAS/api/1.0/nodes/node-345fea0a-9f84-11e3-88be-525400429c50/
    series: precise
services:
  mysql:
    charm: cs:precise/mysql-35
    exposed: false
    life: dying
    relations:
      cluster:
      - mysql
      db:
      - wordpress
    units:
      mysql/0:
        agent-state: started
        agent-version: 1.16.6.1
        life: dying
        machine: "0"
        public-address: node-1.master

Partie de la sortie de juju status (oui, elle se termine à db: - mysql)

  wordpress:
    charm: cs:precise/wordpress-21
    exposed: false
    life: dying
    relations:
      db:
      - mysql

Journaux associés (juju debug-log) :

node-1: 014-03-03 19:32:12 INFO juju runner.go:253 worker: start "uniter"
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter uniter.go:83 l'unité "mysql/0" a démarré
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter modes.go:421 ModeInit démarrage
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter modes.go:29 mise à jour des adresses de l'unité
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter.filter filter.go:454 l'unité est en train de mourir
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:504 vérification du charme sautée, l'unité est en train de mourir
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter modes.go:54 réconciliation de l'état de la relation
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:322 changement de service obtenu
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter uniter.go:517 rejoindre la relation "wordpress:db mysql:db"
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:504 vérification du charme sautée, l'unité est en train de mourir
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:338 changement de relations obtenu
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:314 changement d'unité obtenu
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter uniter.go:543 relation jointe "wordpress:db mysql:db"
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter modes.go:423 ModeInit sortie
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter modes.go:421 ModeContinue démarrage
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter modes.go:67 chargement de l'état de l'unité
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter modes.go:108 crochet "config-changed" non confirmé trouvé
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter uniter.go:363 en cours de validation du crochet "config-changed"
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:330 changement de configuration obtenu
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter.filter filter.go:334 préparation d'un nouvel événement de configuration
node-1: 014-03-03 19:32:12 ERROR juju git.go:188 worker/uniter/charm: échec de la commande git : statut de sortie 128
node-1: chemin : /var/lib/juju/agents/unit-mysql-0/charm
node-1: arguments : []string{"commit", "--allow-empty", "-m", "Terminé \"config-changed\" hook."}
node-1: erreur : le fichier d'objet .git/objects/d4/7f136f29e2319929b668b4e7917dca934b462f est vide
node-1: fatal : l'objet lâche d47f136f29e2319929b668b4e7917dca934b462f (stocké dans .git/objects/d4/7f136f29e2319929b668b4e7917dca934b462f) est corrompu
node-1: 014-03-03 19:32:12 DEBUG juju.worker.uniter modes.go:423 ModeContinue sortie
node-1: 014-03-03 19:32:12 INFO juju.worker.uniter uniter.go:105 l'unité "mysql/0" s'arrête : ModeContinue : échec de validation git : statut de sortie 128
node-1: 014-03-03 19:32:12 ERROR juju.worker.uniter.filter filter.go:117 tombeau : en train de mourir
node-1: 014-03-03 19:32:12 ERROR juju runner.go:211 worker: sorti "uniter" : ModeContinue : échec de validation git : statut de sortie 128
node-1: 014-03-03 19:32:12 INFO juju runner.go:245 worker: redémarrage de "uniter" dans 3s
node-1: 014-03-03 19:32:15 INFO juju runner.go:253 worker: start "uniter"
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter uniter.go:83 l'unité "mysql/0" a démarré
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter modes.go:421 ModeInit démarrage
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter modes.go:29 mise à jour des adresses de l'unité
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter.filter filter.go:454 l'unité est en train de mourir
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:504 vérification du charme sautée, l'unité est en train de mourir
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter modes.go:54 réconciliation de l'état de la relation
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:322 changement de service obtenu
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter uniter.go:517 rejoindre la relation "wordpress:db mysql:db"
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:504 vérification du charme sautée, l'unité est en train de mourir
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:338 changement de relations obtenu
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:314 changement d'unité obtenu
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter uniter.go:543 relation jointe "wordpress:db mysql:db"
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter modes.go:423 ModeInit sortie
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter modes.go:421 ModeContinue démarrage
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter modes.go:67 chargement de l'état de l'unité
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter modes.go:108 crochet "config-changed" non confirmé trouvé
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter uniter.go:363 en cours de validation du crochet "config-changed"
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:330 changement de configuration obtenu
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter.filter filter.go:334 préparation d'un nouvel événement de configuration
node-1: 014-03-03 19:32:15 ERROR juju git.go:188 worker/uniter/charm: échec de la commande git : statut de sortie 128
node-1: chemin : /var/lib/juju/agents/unit-mysql-0/charm
node-1: arguments : []string{"commit", "--allow-empty", "-m", "Terminé \"config-changed\" hook."}
node-1: erreur : le fichier d'objet .git/objects/d4/7f136f29e2319929b668b4e7917dca934b462f est vide
node-1: fatal : l'objet lâche d47f136f29e2319929b668b4e7917dca934b462f (stocké dans .git/objects/d4/7f136f29e2319929b668b4e7917dca934b462f) est corrompu
node-1: 014-03-03 19:32:15 DEBUG juju.worker.uniter modes.go:423 ModeContinue sortie
node-1: 014-03-03 19:32:15 INFO juju.worker.uniter uniter.go:105 l'unité "mysql/0" s'arrête : ModeContinue : échec de validation git : statut de sortie 128
node-1: 014-03-03 19:32:15 ERROR juju.worker.uniter.filter filter.go:117 tombeau : en train de mourir
node-1: 014-03-03 19:32:15 ERROR juju runner.go:211 worker: sorti "uniter" : ModeContinue : échec de validation git : statut de sortie 128
node-1: 014-03-03 19:32:15 INFO juju runner.go:245 worker: redémarrage de "uniter" dans 3s

Veuillez me faire savoir s'il y a une solution facile? Toute suggestion serait appréciée. Merci.

2voto

Ilya Points 2279

Je ne suis pas à 100% certain que cela fonctionne avec MAAS - mais je sais que cette méthode fonctionne avec d'autres fournisseurs. Lorsque je veux détruire un service et qu'il est "bloqué" dans un état mourant, en utilisant le déploiement de votre wordpress comme exemple :

juju resolve wordpress/0

Maintenant, si cela échoue pour aider la situation, donc, s'il continue d'aller d'un crochet à l'autre dans un état d'erreur, je détruirai la machine avec une extrême prédilection. (notez bien, cela entraînera la destruction irrécupérable de la machine, et cela doit être traité avec prudence, comme toute opération rm -rf - cela détruira la machine en question)

Obtenez l'identifiant de la machine à partir de la commande juju status - puis :

 juju destroy-machine --force 

Si cela continue à laisser le service mysql dans un état de détresse, vous pouvez le résoudre manuellement en suivant le flux de travail ci-dessus :

juju resolve mysql/0

Si tout échoue, et que vous ne vous souciez pas des données

juju destroy-machine --force 

En ce qui concerne la sortie du journal - sachez qu'il y a un effort pour éloigner juju de l'utilisation de git, afin que des problèmes isolés comme celui-ci ne surviennent pas pour les utilisateurs finaux. Je n'ai pas de date prévue pour quand cette fonctionnalité sera disponible mais elle est en cours de développement actuellement.

SistemesEz.com

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.

Powered by:

X