Docker pojemnik ze statusem „martwy” po konsul Healthcheck biegnie

Question

używam funkcji Healthcheck konsula, a ja wciąż otrzymuję te te „martwe” kontenery:

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

Co to jest dokładnie „Dead” kontener? Kiedy zatrzymany pojemnik staje się "martwy"?

Dla przypomnienia używam progrium/consul + gliderlabs/rejestrator obrazów + SERVICE_XXXX_CHECK zmienne env do sprawdzania stanu zdrowia. Uruchamia skrypt sprawdzania kondycji, który uruchamia obraz co X sekund, coś podobnego do docker run --rm my/img healthcheck.sh Jestem zainteresowany ogólnym pojęciem tego, co "martwe" oznacza i jak temu zapobiec. Inną osobliwą rzeczą jest to, że moje martwe pojemniki nie mają imienia.

jest kilka informacji z kontroli kontenera:

"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" 
    }, 

Najdziwniejsze jest to, że tylko co jakiś pojemnik staje się martwa i nie jest usuwany.

Dziękuję

Edit: Patrząc na dzienniki, znalazłem to, co sprawia, że ​​pojemnik nie przystanek:

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 

Dlaczego tak się dzieje?

Edit2: znaleźć to: https://github.com/docker/docker/issues/9665

Answer 1

Aktualizacja marzec 2016: issue 9665 właśnie został zamknięty przez PR 21107 (dla docker 1.11 ewentualnie)
To powinno pomóc uniknąć "aufs kierowcy nie udało się usunąć głównego systemu plików", " problem "zajętości urządzenia lub zasobów".

---

Original odpowiedź maja 2015

Martwe jest jednym jeśli container states, który jest testowany przez Container.Start()

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

Jest set Dead when stopping fails, w celu zapobieżenia, że ​​pojemnik do ponownego uruchomienia.

Wśród możliwych przyczyn awarii, see container.Kill().
Oznacza to, że oba błędy uległy awarii.

// 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 { 

Zazwyczaj oznacza to, jak wspomina OP, o zajętości urządzenia lub zasobu, uniemożliwiające zabicie procesu.

Answer 2

Występuje wiele błędów spowodowanych przez EBUSY, w szczególności gdy użyto devicemapper.

Występuje błąd śledzenia wszystkich powiązanych problemów związanych z EBUSY. zobacz https://github.com/docker/docker/issues/5684#issuecomment-69052334