Conteneur Docker avec le statut de “Mort” après consul bilan de santé fonctionne

Je suis à l'aide du consul de bilan de santé de la fonctionnalité, et je continue à recevoir ces de ces "morts" dans les conteneurs:

CONTAINER ID  IMAGE                   COMMAND              CREATED         STATUS              PORTS                                                                                                                                                                    NAMES
20fd397ba638  progrium/consul:latest  "\"/bin/bash -c 'cur 15 minutes ago  Dead

Ce qu'est exactement une "Mort" conteneur? Quand un arrêté conteneur deviennent des "Morts"?

Pour l'enregistrement, je lance progrium/consul + gliderlabs/registrator images + SERVICE_XXXX_CHECK des variables d'environnement pour faire de la santé de la vérification. Il effectue un bilan de santé script qui s'exécute une image toutes les X secondes, quelque chose comme docker run --rm my/img healthcheck.sh

Je m'intéresse en général à ce que "mort" signifie et comment faire pour l'empêcher de se produire. Un autre, quelque chose d'étrange, c'est que ma mort conteneurs n'ont pas de nom.

ce n'est un peu d'info de l'inspection des conteneurs:

  "State": {
        "Dead": true,
        "Error": "",
        "ExitCode": 1,
        "FinishedAt": "2015-05-30T19:00:01.814291614Z",
        "OOMKilled": false,
        "Paused": false,
        "Pid": 0,
        "Restarting": false,
        "Running": false,
        "StartedAt": "2015-05-30T18:59:51.739464262Z"
    },

La chose étrange est que seulement chaque maintenant et puis un conteneur devient mort et n'est pas supprimé.

Merci

Edit:
En regardant les logs, j'ai trouvé ce qui rend le conteneur arrêter l'échec:

  Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container 003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc: 
Driver aufs failed to remove root filesystem 003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc: 
rename /var/lib/docker/aufs/diff/003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc 
/var/lib/docker/aufs/diff/003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc-removing: 
device or resource busy

Pourquoi cela se produit?

edit2:
trouvé ceci: https://github.com/docker/docker/issues/9665

J'ai édité ma réponse: question 965 vient d'être fermé.
génial, merci

OriginalL'auteur Giovanni Caporaletti | 2015-05-30

  1. 14

    Mise à jour: Mars 2016: question 9665 vient d'être fermé par PR 21107 (pour docker 1.11 peut-être)

    Cela devrait aider à éviter le "Pilote aufs n'a pas à supprimer le système de fichier root", "périphérique ou ressource occupé" problème.

    Réponse originale à cette question en Mai 2015

    Morts est un si la conteneur des etats, qui est testé par Conteneur.Start()

    if container.removalInProgress || container.Dead {
        return fmt.Errorf("Container is marked for removal and cannot be started.")
}

    Il est ensemble de Morts lors de l'arrêt échoue, afin d'éviter que le conteneur à redémarrer.

    Parmi les causes possibles de l'échec, reportez-vous à conteneur.Kill().

    Cela signifie kill -15 et kill -9 sont à la fois un échec.

    //1. Send a SIGTERM
if err := container.killPossiblyDeadProcess(15); err != nil {
    logrus.Infof("Failed to send SIGTERM to the process, force killing")
    if err := container.killPossiblyDeadProcess(9); err != nil {

    Qui signifie généralement, comme l'OP oublier, un périphérique ou ressource occupé, empêchant le processus d'être tué.

    En regardant le code, je suis allé à la recherche pour les journaux, et j'ai trouvé quelque chose. J'ai juste modifié la question principale
    En effet. J'ai ajouté la partie du code qui essayez d'envoyer le tuer signaux.
    Bon, je crois qu'il n'y a pas de solution à ce "device busy" problème, le ticket est toujours ouvert et actif. Je vais voir si quelqu'un d'autre a quelque chose à dire et puis accepter votre réponse, car elle explique principalement ce que "mort".

    OriginalL'auteur VonC

  2. 1

    Il y a beaucoup de bugs causés par EBUSY, en particulier lorsque devicemapper est utilisé.

    Il est un tracker de bug pour l'ensemble de la EBUSY questions connexes.
    voir https://github.com/docker/docker/issues/5684#issuecomment-69052334

    OriginalL'auteur dnozay