@vieira Пожалуйста, перезагрузите компьютер и сообщите нам, если у вас по-прежнему возникают проблемы.

Вышеуказанные шаги можно воспроизвести даже после перезагрузки компьютера.

@alexlarsson, не могли бы вы взглянуть? Похоже, это связано с devicemapper

Проблема, похоже, связана с устройством сопоставления устройств. Я думаю, это действительно что-то другое.
Я пробовал это, и проблема в части "остановить докер". Если я просто ctrl-c демону докера, он попытается правильно остановить контейнеры, но похоже, что ему никогда не удается остановить контейнер. Итак, я ctrl-c еще несколько раз, чтобы заставить docker умереть.

На данный момент контейнер (хвост) все еще работает, поэтому устройство сопоставления устройств будет смонтировано, а это означает, что мы не можем смонтировать его снова или удалить. Вот почему эти операции терпят неудачу.

@alexlarsson , знаете ли вы, как легко очистить систему, если что-то пойдет не так?

Что ж, если вы обнаружите сбежавший процесс контейнера, возможно, вы сможете принудительно убить его.

@vieira вы можете размонтировать:
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

и снова запустите контейнер, он должен работать

Я вижу, что мой докер был запущен с -d и -r. Во-первых, при перезапуске докера контейнеры не перезапускаются. Затем происходит указанная выше ошибка (при попытке запустить контейнер (ы)).

Мой centos 6.5 все еще получает 1.0.0.6 от epel. Было ли это когда-либо идентифицировано как ошибка в 1.0 и исправлено в 1.1? Кто-нибудь может подтвердить?

благодаря

Всем привет, до сих пор не исправлено в 1.1.1.
Действия, описанные в исходной публикации, все еще применимы

Error response from daemon: Cannot start container 5e9bde9b409b: 
Error getting container 5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d 
from driver devicemapper: 
Error mounting '/dev/mapper/docker-253:0-267081-5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d' 
on 
'/var/lib/docker/devicemapper/mnt/5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d': 
device or resource busy

Я тоже получаю много, но, похоже, в каком-то смысле он удаляет контейнер (в том смысле, что я могу запустить новый контейнер с тем же именем)

Есть ли способ решения этой проблемы?

Также ищу обходной путь.

Похоже на остановку всех контейнеров до того, как демон докера исправит проблему.

Я добавил этот блок pre-stop в свою выскочку в качестве обходного пути:

pre-stop script
    /usr/bin/docker ps -q | xargs /usr/bin/docker stop
end script

Вот суть моих шагов отладки: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

@rochacon Спасибо за обходной путь. Сегодня-завтра протестирую с 1.2 (кажется, вы тестировали с 1.1.1, да?). Надеюсь, что это работает.

@vieira Я тоже пробовал с 1.2.0, те же результаты.

После 4 недель работы один из моих контейнеров остановился ... Не знаю почему ... Как я могу найти основную причину?

В любом случае, у меня была такая же проблема ... Она была решена с помощью предложения от @aroragagan : umount, контейнер запуска

root<strong i="8">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
Error response from daemon: Cannot start container federated-registry: Error getting container 4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-394842-4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946' on '/var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946': device or resource busy
2014/10/17 21:04:33 Error: failed to start one or more containers

[root<strong i="9">@pppdc9prd3ga</strong> mdesales]# docker version
Client version: 1.1.2
Client API version: 1.13
Go version (client): go1.2.2
Git commit (client): d84a070/1.1.2
Server version: 1.1.2
Server API version: 1.13
Go version (server): go1.2.2
Git commit (server): d84a070/1.1.2

[root<strong i="10">@pppdc9prd3ga</strong> mdesales]# umount /var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946

[root<strong i="11">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
federated-registry

Мы видим это в 1.3.0 сейчас, в системе EC2 Ubuntu, которая была обновлена ​​с 12.04 до 14.04. Мой экземпляр разработчика представляет собой прямую установку 14.04 в Vagrant и не имеет этой проблемы. Размонтирование, а затем перезапуск контейнеров, похоже, работает, но это лишает смысла их настройку на автоматический перезапуск при перезагрузке экземпляра или при перезапуске докера. Дайте мне знать, если я могу предоставить дополнительную информацию о версиях поддерживающих пакетов и т. Д., Поскольку у меня есть рабочая и нерабочая система.

Аналогичная проблема наблюдается с docker 1.3 Ubuntu 14.04 с ядром Linux 3.13 или 3.14.

@srobertson , вы имеете в виду, что "контейнеры не перезапускаются при перезапуске демона"? Вы используете новую политику перезапуска для каждого контейнера? Поскольку общедоступный -r / --restart=true был удален в Docker 1.2

Новая (для каждого контейнера) политика перезапуска описана в справочнике по

+1, эта проблема возникла на докере 1.3 @ ArchLinux x86_64 с ядром 3.17.2-1-ARCH.

$ docker --version
Docker version 1.3.1, build 4e9bbfa

Umount решает проблему.

umount - это обходной путь, я бы не сказал, что он решает проблему. Просто перезапустите демон с запущенными контейнерами, чтобы воспроизвести проблему.

umount у меня тоже работает в следующей версии докера:

atc@li574-92> docker --version
Docker version 1.3.1, build 4e9bbfa

Затем я сначала остановил демон докера:

umount /dev/mapper/docker-202\:0-729439-a7c53ae579d02aa7bb3aeb2af5f2f79c295e1f5962ec53f16b73896bb3970635 

@ mlehner616 Да, ты прав. Извините, конечно, это обходной путь, а не решение. Это был просто плохой выбор слов.

Я бы тоже хотел, чтобы это было исправлено, конечно. знак равно

fyi, unmounten у меня не сработал. Я получаю сообщение об ошибке, что в / etc / mtab нет монтирования
Докер версии 1.0.0, сборка 63fe64c / 1.0.0 на RHEL 6.5

Я обошел это, автоматически отключив все старые монтирования, когда демон докеров вернется. Я не хотел исправлять большой /etc/init/docker.conf ubuntu, поэтому вместо этого я поместил небольшую строку в /etc/default/docker :

cat /proc/mounts | grep "mapper/docker" | awk '{print $2}' | xargs -r umount

Кажется, это помогает. Я совместил это с выскочкой, управляющей запуском и возрождением моих реальных контейнеров докеров, так что теперь после service docker restart все контейнеры просто вернутся.

Спасибо, @jypma , это тоже

_review session_ с @unclejack

Мы собираемся использовать эту проблему в качестве средства отслеживания для большинства отчетов «Устройство или ресурс занят» или отчетов EBUSY .

Эта проблема, как и другие, устраняется за счет правильной обработки пространства имен монтирования демона докера. В настоящее время нет обработки по умолчанию для пространства имен монтирования, поэтому у нас есть проблемы, подобные этому EBUSY.

Пока мы работаем над официальным решением для этой проблемы, вы можете применить обходные пути самостоятельно. См. Http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Подтверждая, что я столкнулся с этой проблемой, используя стандартный образ freeipa. Я остановил службу докеров, и когда я попытался перезапустить ее вместе с контейнером ipa, я получил следующее.

$ docker start ipa
Error response from daemon: Cannot start container ipa: Error getting container 98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-786581-98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2' on '/var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2': device or resource busy
2015/01/11 21:44:38 Error: failed to start one or more containers

Размонтирование «монтирования» помогло решить проблему, так что я смог перезапустить контейнер.

$ umount /var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2

$ docker start ipa
ipa

Используя следующее:

$  docker version
Client version: 1.3.2
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 39fa2fa/1.3.2
OS/Arch (client): linux/amd64
Server version: 1.3.2
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 39fa2fa/1.3.2

$ lsb_release -i -d
Distributor ID: CentOS
Description:    CentOS release 6.6 (Final)

umount исправил мою проблему

docker --version
Докер версии 1.3.2, сборка 39fa2fa

Таким образом, следующий обходной путь - это немного более постоянный обходной путь для моего варианта использования.
Я строго использую Amazon linux (RedHat6-Like), поэтому я немного изменил сценарий инициализации (который, вероятно, будет перезаписан, если докер будет обновлен). В основном все, что это делает, - это обычная остановка докера, проверка оставшихся монтировок докеров , если есть, он их размонтирует. YMMV

_ / и т.д. / init.d / docker_
Добавление переменной lib (строка ~ 28)

prog="docker"
exec="/usr/bin/$prog"
# Adding lib variable here
lib="/var/lib/$prog"
pidfile="/var/run/$prog.pid"
lockfile="/var/lock/subsys/$prog"
logfile="/var/log/$prog"

Добавление блока umount в функцию остановки (строка ~ 77)

stop() {
    echo -n $"Stopping $prog: "
    killproc -p $pidfile -d 300 $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile

    # BEGIN UMOUNT BLOCK
    if [ $(df | grep $lib | awk '{print $1}' | wc -l) -gt 0 ]; then
        umount $(df | grep $lib | awk '{print $1}')
    fi
    # END UMOUNT BLOCK
    return $retval
}

У меня та же проблема с докером 1.4.1, использующим устройство сопоставления в качестве драйвера хранилища. Мне удалось собрать трассировку стека паники из докера через его файл журнала.

ОКРУЖАЮЩАЯ ОБСТАНОВКА

$ cat / etc / * выпуск
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME = надежный
DISTRIB_DESCRIPTION = "Ubuntu 14.04.1 LTS"
ИМЯ = "Ubuntu"
VERSION = "14.04.1 LTS, Trusty Tahr"
ID = ubuntu
ID_LIKE = debian
PRETTY_NAME = "Ubuntu 14.04.1 LTS"
VERSION_ID = "14.04"
HOME_URL = " http://www.ubuntu.com/ "
SUPPORT_URL = " http://help.ubuntu.com/ "
BUG_REPORT_URL = " http://bugs.launchpad.net/ubuntu/ "

версия $ docker
sudo: невозможно разрешить хост ip-172-30-0-39
Версия клиента: 1.4.1
Версия клиентского API: 1.16
Версия Go (клиент): go1.3.3
Git commit (клиент): 5bc2ff8
ОС / Arch (клиент): linux / amd64
Версия сервера: 1.4.1
Версия серверного API: 1.16
Версия Go (сервер): go1.3.3
Git commit (сервер): 5bc2ff8

$ tail -f / var / log / выскочка / докер
...
INFO [143413] -job execResize (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121, 37, 130)
2015/01/22 22:29:22 http: panic serve @: ошибка времени выполнения: недопустимый адрес памяти или разыменование нулевого указателя
goroutine 1932 [работает]:
net / http.func · 011 ()
/usr/local/go/src/pkg/net/http/server.go:1100 + 0xb7
runtime.panic (0xbe5c40, 0x127da13)
/usr/local/go/src/pkg/runtime/panic.c:248 + 0x18d
github.com/docker/docker/daemon.(_execConfig).Resize(0xc20989c800, 0x25, 0x82, 0x0, 0x0)
/go/src/github.com/docker/docker/daemon/exec.go:65 + 0x66
github.com/docker/docker/daemon.(_Daemon).ContainerExecResize(0xc208044f20, 0xc20a836e00, 0x1)
/go/src/github.com/docker/docker/daemon/resize.go:49 + 0x314
github.com/docker/docker/daemon._Daemon.ContainerExecResize·fm(0xc20a836e00, 0x7f49bcd007d8)
/go/src/github.com/docker/docker/daemon/daemon.go:132 + 0x30
github.com/docker/docker/engine.(_Job).Run(0xc20a836e00, 0x0, 0x0)
/go/src/github.com/docker/docker/engine/job.go:83 + 0x837
github.com/docker/docker/api/server.postContainerExecResize(0xc208114fd0, 0xc20a55db27, 0x4, 0x7f49bcd08c58, 0xc209498320, 0xc209e
621a0, 0xc20a69c0c0, 0x0, 0x0)
/go/src/github.com/docker/docker/api/server/server.go:1170 + 0x2d1
github.com/docker/docker/api/server.func·002(0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/go/src/github.com/docker/docker/api/server/server.go:1219 + 0x810
net / http.HandlerFunc.ServeHTTP (0xc2081b8280, 0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/usr/local/go/src/pkg/net/http/server.go:1235 + 0x40
github.com/gorilla/mux.(_Router).ServeHTTP(0xc2080a3cc0, 0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/go/src/github.com/docker/docker/vendor/src/github.com/gorilla/mux/mux.go:98 + 0x297
net / http.serverHandler.ServeHTTP (0xc208180480, 0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/usr/local/go/src/pkg/net/http/server.go:1673 + 0x19f
сеть / http. (_ conn) .serve (0xc20a836300)
/usr/local/go/src/pkg/net/http/server.go:1174 + 0xa7e
создается net / http. (* Server) .Serve
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

ИНФОРМАЦИЯ [0056] УДАЛИТЬ /v1.16/containers/hoopla_docker_registry
ИНФОРМАЦИЯ [0056] + работа rm (hoopla_docker_registry)
Невозможно уничтожить контейнер hoopla_docker_registry: драйверу devicemapper не удалось удалить корневую файловую систему 6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c: Устройство занято
ИНФОРМАЦИЯ [0066] -задание rm (hoopla_docker_registry) = ERR (1)
ERRO [0066] Обработчик DELETE / container / { name :. *} вернул ошибку: не удалось уничтожить контейнер hoopla_docker_registry: диск
r devicemapper не удалось удалить корневую файловую систему 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: Устройство занято

ERRO [0066] Ошибка HTTP: statusCode = 500 Невозможно уничтожить контейнер hoopla_docker_registry: драйверу devicemapper не удалось удалить корневую файловую систему 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: Устройство занято

Я видел это на ubuntu 14.04 (на ec2) с 1.4.1, а также с 1.5. Это странно, потому что докер кажется очень надежным на linux mint 17, но очень ненадежным на нашем сервере сборки с ubuntu 14.04.

Есть ли способ не использовать devicemapper, поскольку эта проблема, похоже, существует уже 0,9 дня?

То же самое может случиться и с overlayfs.

Ну я только что перешился на aufs и пока без проблем.

Каков статус этой проблемы? Я видел, как были объединены некоторые PR, которые могли быть связаны, но ничто из того, что четко указано, не помогло исправить это. Это серьезная проблема в производственной среде, и теперь единственный способ ее решения - исправить сценарий инициализации, чтобы аккуратно размонтировать диски.

после повторного просмотра, это не идеальный пример EBUSY о котором мы говорили изначально.
Этот случай больше связан с pid-идентификаторами контейнера, которые не обрабатывают сигналы изящно.

Поскольку здесь случай воспроизведения tail -f /dev/null не завершается на SIGQUIT когда демон завершает работу, драйвер devmapper не может должным образом разорвать (это не только для devmapper). Перед повторным запуском демона вы можете увидеть, что tail -f /dev/null все еще работает, даже если докер не работает.

Подобная проблема потребует размышлений о том, насколько радикально обрабатывать pid-файлы в контейнере при выходе из докера ... @unclejack @crosbymichael мысли?

Проверено на Fedora 21 x86_64. Предоставление информации только для сравнения, поскольку проблема, похоже, отсутствует (больше?). Те же результаты при использовании изображений centos: 7 или ubuntu: trusty .

$ docker run -d centos:7 tail -f /dev/null
ec496f1a6738430972b79e5f3c9fdbf2527e55817d4638678e3b0dd486191203

$ systemctl stop docker

$ ps ax | grep tail
14681 ?        Ss     0:00 tail -f /dev/null
14738 pts/9    S+     0:00 grep --color=auto tail

$ systemctl start docker

$ docker ps -q

$ docker ps -a -q
ec496f1a6738

$ docker start ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
Error response from daemon: Conflict, You cannot remove a running container. Stop the container before attempting removal or use -f
FATA[0000] Error: failed to remove one or more containers 

$ docker stop ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
ec496f1a6738

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Системная информация:

$ uname -a
Linux localhost 3.18.9-200.fc21.x86_64 #1 SMP Mon Mar 9 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -q device-mapper docker-io
device-mapper-1.02.93-3.fc21.x86_64
docker-io-1.5.0-1.fc21.x86_64

$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

Просто столкнитесь с этим на Docker 1.5, Ubuntu 14.04
root@ip-10-148-25-50:~# docker start service Error response from daemon: Cannot start container service: Error getting container f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 from driver devicemapper: Error mounting '/dev/mapper/docker-202:1-153948-f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774' on '/var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774': device or resource busy FATA[0000] Error: failed to start one or more containers

хотя запуск umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 помог.

У меня такая же проблема с Docker 1.5.0, Centos7.0,

[vagrant<strong i="6">@localhost</strong> ~]$  sudo systemctl start docker
[vagrant<strong i="7">@localhost</strong> ~]$  sudo docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                        PORTS               NAMES
5189b16c0917        mongo:3             "/entrypoint.sh mong   35 minutes ago      Exited (128) 29 minutes ago                       mongod
[vagrant<strong i="8">@localhost</strong> ~]$ sudo docker inspect 5189b16c0917 | grep Error
        "Error": "Error getting container 5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6 from driver devicemapper: Error mounting '/dev/mapper/docker-253:1-134,

umount не работает.

[vagrant<strong i="12">@localhost</strong> ~]$ sudo stat /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
  File: `/var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6'
  Size: 6               Blocks: 0          IO Block: 4096   ディレクトリ
Device: fd01h/64769d    Inode: 201732136   Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-03-21 20:36:14.407505308 +0900
Modify: 2015-03-21 20:16:58.863146490 +0900
Change: 2015-03-21 20:16:58.863146490 +0900
 Birth: -
[vagrant<strong i="13">@localhost</strong> ~]$ sudo umount /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
umount: /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6: not mounted
[vagrant<strong i="14">@localhost</strong> ~]$ grep docker /proc/mounts
(no results)

Окружающая обстановка

[vagrant<strong i="18">@localhost</strong> ~]$ cat /etc/centos-release
CentOS Linux release 7.0.1406 (Core)
[vagrant<strong i="19">@localhost</strong> ~]$ uname -a
Linux localhost.localdomain 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[vagrant<strong i="20">@localhost</strong> ~]$ sudo docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

[vagrant<strong i="21">@localhost</strong> ~]$ rpm -qi docker
Name        : docker
Version     : 1.5.0
Release     : 1.el7
Architecture: x86_64
Install Date: 2015年03月21日 20時04分29秒
Group       : Unspecified
Size        : 27215826
License     : ASL 2.0
Signature   : (none)
Source RPM  : docker-1.5.0-1.el7.src.rpm
Build Date  : 2015年02月12日 05時10分39秒
Build Host  : c1bj.rdu2.centos.org
Relocations : (not relocatable)
Packager    : CBS <[email protected]>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications
Description :
Docker is an open-source engine that automates the deployment of any
application as a lightweight, portable, self-sufficient container that will
run virtually anywhere.

Воспроизводю докером 1.3.2 из официального репозитория CentOS7.

$ rpm -qi docker
Name        : docker
Version     : 1.3.2
Release     : 4.el7.centos
Architecture: x86_64
Install Date: 2015年03月22日 02時44分58秒
Group       : Unspecified
Size        : 25505685
License     : ASL 2.0
Signature   : RSA/SHA256, 2014年12月11日 04時21分03秒, Key ID 24c6a8a7f4a80eb5
Source RPM  : docker-1.3.2-4.el7.centos.src.rpm
Build Date  : 2014年12月11日 04時15分49秒
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications

docker 1.5.0 получил ту же ошибку
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

Здесь та же проблема, легко воспроизвести

docker run -it --name busybox --rm busybox tail -f /dev/null

On another shell:

root<strong i="6">@staging5</strong>:/home/shopmedia #service docker stop
Stopping docker:                                           [  OK  ]
root<strong i="7">@staging5</strong>:/home/shopmedia #service docker start
Starting docker:                                           [  OK  ]
root<strong i="8">@staging5</strong>:/home/shopmedia #docker rm -f busybox
Error response from daemon: Cannot destroy container busybox: Driver devicemapper failed to remove root filesystem 124cd3329e0fafa6be2a284b36a75571666745436c601a702a4beedb75adc7c0: Device is Busy
FATA[0011] Error: failed to remove one or more containers

Окружающая обстановка

docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

cat /etc/centos-release
CentOS release 6.6 (Final)

cat /proc/version
Linux version 2.6.32-504.8.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Jan 28 21:11:36 UTC 2015

rpm -q device-mapper
device-mapper-1.02.90-2.el6_6.1.x86_64

РЕДАКТИРОВАТЬ: Единственный обходной путь для меня (я не использую system.d) - обновить /etc/init.d/docker, строку 50 с помощью команды unshare. Исправление было предоставлено @vbatts , спасибо, кстати
Однако это исправление не масштабируется. Мы не хотим обновлять каждую машину, которая у нас есть + она будет удалена при следующем обновлении докера.

1. Какие у меня другие варианты?
2. Выходит ли сторона фиксированного докера?
3. Это влияет на всю операционную систему?
4. Это влияет на все ядра?

благодаря

Думаю, https://github.com/docker/docker/pull/12400 исправит это. Это связано с тем, что завершение работы демона docker приведет к тому, что запущенные контейнеры останутся не очищенными (если контейнеры не будут уничтожены в течение 10 секунд, rootfs контейнера все равно будут смонтированы), и он не может быть удален при следующем запуске демона. (Тестирую на оверлее)

Спасибо @ coolljt0725 .

1) В какой версии докера он будет реализован?
2) Какие у меня другие варианты?
3) Это влияет на всю операционную систему?
4) На все ядра влияет?

благодаря

+1 для обходного пути umount. со мной случилось с докером 1.6.0, сборка 4749651.
перезапуск службы докера не решил эту проблему. размонтировать проблемный «том» исправил.

Docker 1.6.1 (Ubuntu 14.04) по-прежнему имеет эту проблему. umount работает.

Docker 1.6.2 (Ubuntu 14.04) umount не работает

Docker 1.7.0 Centos 6.5 по-прежнему имеет те же проблемы.

Я только что получил это на Centos 6.3 после обновления до Docker 1.7. Обновление перезапустило докер (очевидно), и когда я пошел перезапускать контейнеры, все мои контейнеры node.js перезапустились, но те, которые запускают uwsgi, выдают ошибку:

# docker start 48596c91d263
Error response from daemon: Cannot start container 48596c91d263: Error getting container 48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 from driver devicemapper: Error mounting '/dev/mapper/docker-8:17-262147-48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549' on '/local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549': device or resource busy

Выполнение umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 НЕ устранило проблему.

То же самое и в Debian. Невозможно запустить ни один контейнер, даже при получении полностью свежего образа hello-world.

root<strong i="6">@vamp1</strong>:~# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from hello-world
a8219747be10: Pull complete 
91c95931e552: Already exists 
hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provi
de security.
Digest: sha256:aa03e5d0d5553b4c3473e89c8619cf79df368babd18681cf5daeb82aab55838d
Status: Downloaded newer image for hello-world:latest
Error response from daemon: Cannot start container 69be8cff86828d1f4ca3db9eeeeb1a8891ce1e305bd07847108750a0051846ff: device or resource busy

Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

@tnolet Предоставьте docker info .

@unclejack docker info для моего хоста

$ docker info
Containers: 24
Images: 128
Storage Driver: devicemapper
 Pool Name: docker-8:17-262147-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.897 GB
 Data Space Total: 107.4 GB
 Data Space Available: 104.5 GB
 Metadata Space Used: 7.918 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.14 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.81-1.el6.elrepo.x86_64
Operating System: <unknown>
CPUs: 4
Total Memory: 7.812 GiB
Name: radioedit-app101
ID: RY22:ODAC:5NT5:MSBZ:Y52X:L33V:UCHA:IOIL:SR23:YX3U:IILJ:J44R
WARNING: No swap limit support

@tdterry RHEL 6 и CentOS 6 больше не поддерживаются Red Hat для использования с Docker. Пожалуйста, обновитесь до RHEL 7 или CentOS 7.

Docker официально поддерживает Centos 6.5 (https://docs.docker.com/installation/centos/). Кроме того, мы обновили ядро ​​до версии 3.10. Другие люди здесь сообщают, что ошибка существует и в CentOS 7. Это больше похоже на проблему с устройством отображения, чем на проблему с версией CentOS. У меня нет причин полагать, что при обновлении до CentOS 7 все будет иначе.

У меня это было только в CentOS 7, Docker версии 1.6.0, сборка 4749651 с devicemapper. Все мои 15 контейнеров разбились. Я пытаюсь удалить несколько оборванных изображений и получаю ту же ошибку:

Error response from daemon: Cannot destroy container: Driver devicemapper failed to remove root filesystem : Device is Busy

Containers: 25
Images: 237
Storage Driver: devicemapper
 Pool Name: docker-253:2-8594920394-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 22.03 GB
 Data Space Total: 107.4 GB
 Data Space Available: 85.34 GB
 Metadata Space Used: 25.47 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.122 GB
 Udev Sync Supported: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.4.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 24
Total Memory: 141.5 GiB
Name: localhost.localdomain

@amalagaura с остановленным демоном, запуск mount | grep docker может показать несколько смонтированных каталогов (например, /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). вы можете сначала umount , а затем снова запустить демон. Если проблема все еще существует, dmsetup ls | grep docker и посмотрите записи вроде docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . Из которых вы можете назвать dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts Спасибо за помощь. Наша настоящая проблема в том, что наш производственный кластер из 15 машин просто умер. Это другое обсуждение, но что делать, если нам нужна поддержка докеров?

У меня возникла аналогичная проблема после обновления до 1.7, она нормально работала в 1.6.2 на elementaryOS.

Всякий раз, когда я запускаю какой-либо контейнер, я получаю сообщение

Ответ об ошибке от демона: не удается запустить контейнер 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a: устройство или ресурс занят

Я очистил докер, rm -rf / var / lib / docker, и при новой установке все еще получаю ту же ошибку при запуске образа hello-world.

Я также заметил, что папки накапливаются в / var / docker / lib / aufs / mnt после каждой неудачной попытки.

Я нажимаю на это очень часто, и я использую aufs, а не devicemapper:

$ sudo docker info
Containers: 3
Images: 2278
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 2284
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.5.0-54-generic
Operating System: Ubuntu precise (12.04.2 LTS)
CPUs: 8
Total Memory: 7.725 GiB
Name: (omitted)
ID: DWS4:G2M5:XD2Q:CQKA:5OXF:I3RB:6M6F:GUVO:NUFM:KKTF:4RB2:X3HP

Сообщите мне, если я могу предоставить дополнительную информацию по отладке.

Видя ту же проблему. umount не работает, говорит, что папка не смонтирована. Я наблюдал это с docker 1.5.0, затем я обновился до 1.7.1 с тем же эффектом.

$ docker info
Containers: 15
Images: 91
Storage Driver: devicemapper
 Pool Name: docker-202:1-149995-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.225 GB
 Data Space Total: 107.4 GB
 Data Space Available: 105.1 GB
 Metadata Space Used: 5.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.142 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-40-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 1
Total Memory: 3.676 GiB
WARNING: No swap limit support

То же самое на ubuntu 14.04

$ docker info
Containers: 6
Images: 537
Storage Driver: devicemapper
 Pool Name: docker-8:1-262623-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file:
 Metadata file:
 Data Space Used: 7.546 GB
 Data Space Total: 107.4 GB
 Data Space Available: 99.83 GB
 Metadata Space Used: 19.05 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.128 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-52-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 2
Total Memory: 2.939 GiB
Name: test-app
ID: F5T4:5AIR:TDBZ:DGH4:WBFT:ZX6A:FVSA:DI4O:5HE2:CJIV:VVLZ:TGDS
WARNING: No swap limit support

$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

Я собираюсь запустить приложение, и независимо от того, решена ли эта проблема, я не могу использовать докер в производственной среде, так как у меня уже произошел сбой некоторых контейнеров, и я не мог удалить их без перезагрузки системы, что является проблемой для производственной системы.

@trompx devicemapper с отключенной синхронизацией udev работать не будет.
Это одна из причин, по которой мы теперь предлагаем динамические двоичные файлы (что устраняет проблему синхронизации) вместо статических двоичных файлов.
Я бы рекомендовал заменить ваши репозитории с get.docker.com (и пакет lxc-docker) репозиторием apt.dockerproject.org (и пакетом docker-engine).
См. Http://blog.docker.com/2015/07/new-apt-and-yum-repos/ для получения дополнительных сведений.

Также существует новое (ish) состояние контейнера, называемое "мертвым", которое устанавливается, когда возникают проблемы с удалением контейнера. Это, конечно, обход этой конкретной проблемы, который позволяет вам исследовать, почему возникает ошибка device or resource busy (возможно, состояние гонки), и в этом случае вы можете попытаться удалить снова или попытаться вручную исправить (например, размонтировать все оставшиеся крепления, а затем удалить).

Возможно, графические драйверы могут быть немного более устойчивыми в случаях, когда у нас есть какая-то гонка с fs (например, если она попытается снова размонтировать).

@ cpuguy83 Спасибо за информацию. Сейчас я использую последнюю версию с udev true, но пока я пытался настроить систему мониторинга журналов, возникла проблема, в результате чего все мои контейнеры со статусом «Exited (137)», затем «мертвые», и попытка удалить их мешает мне удаление их «Ответ об ошибке от демона: Невозможно уничтожить контейнер 9ca0b5642a55: Драйвер devicemapper не смог удалить корневую файловую систему». Так что у меня все еще есть эта проблема.

Я не мог видеть, что произошло, поскольку я использую драйвер системного журнала (чтобы попытаться настроить мою систему ведения журнала), поэтому я действительно не знаю, что произошло. Я дам вам знать, если разберусь с этим.

@trompx Если они остались после предыдущей установки, это может вызвать проблему.
Как только контейнеры находятся в "мертвом" состоянии, вы можете docker rm -f их снова, чтобы удалить их из докера, и они больше не должны появляться. Вероятно, файлы отсутствуют, поэтому devicemapper не может их найти.

Мне удалось снова вызвать сбой, но с включенным драйвером журнала json. После проверки журналов всех контейнеров только один haproxy возвращает полезный ввод "/run.sh: fork: Cannot allocate memory". У меня было немного нехватки памяти без подкачки, и, должно быть, у меня закончилась память. Если это причина, означает ли это, что Docker выйдет из строя, когда ему не хватит памяти, что приведет к выходу из всех контейнеров?

@trompx Разумеется, ничто не
Контейнеры не выходят из строя, если докер выйдет из строя, однако, когда докер запускает резервную копию, он убивает все запущенные контейнеры (и запускает те, которые имеют политику перезапуска).

Я наблюдаю это довольно часто при использовании docker-compose 1.4.2 и docker-engine 1.8.3 в Ubuntu 14.04.

@superdump версия ядра?

@gionn : 3.13.0-65-общий

@superdump @gionn то же самое, что и версии программного обеспечения, ядро ​​3.13.0-67-generic

на AWS с использованием твердотельных накопителей EBS

Кто-нибудь пробовал с докером 1.9, чтобы узнать, исправили ли это? Были некоторые работы, связанные с томами ...

Объемы (в смысле расширения данных за пределы жизненного цикла контейнера) - это другая функция, чем то, что здесь затрагивается, не так ли?

Если скрытые монтирования - это работоспособное решение этих проблем, не может ли докер сделать это по умолчанию при запуске демона ..?
Это должно быть достаточно просто для реализации ..

Это просто сделать, и есть разные способы выполнить эту задачу. В
сопровождающие не хотели принимать запросы на вытягивание, которые делали это, потому что
был «взлом».
В пятницу, 27 ноября 2015 г., в 6:49 Андреас Стениус [email protected]
написал:

Если скрытые монтирования - работоспособное решение этих проблем, докер не может
что по умолчанию при запуске демона ..?
Это должно быть достаточно просто для реализации ..

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

Это не правда. У нас было это, и это вызывало проблемы, поэтому мы вернули его. Для вас это тривиально, если это не вызывает у вас никаких проблем.

Спасибо за информацию. Мы добавили запрет на общий доступ к нескольким узлам,
посмотрим, как это будет ...
фр 27 ноя. 2015 кл. 19:01 skrev Брайан Гофф [email protected] :

Это не правда. У нас было это, и это вызывало проблемы, поэтому мы вернули его.
Для вас это тривиально, если это не вызывает у вас никаких проблем.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

Привет,

При использовании Docker у меня возникает описанная выше проблема.

Failed to remove container (da3b06dc0723): Error response from daemon: Unable to remove filesystem for da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f: remove /var/lib/docker/containers/da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f/shm: device or resource busy
Failed to remove container (99cfba26be16): Error response from daemon: Unable to remove filesystem for 99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855: remove /var/lib/docker/containers/99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855/shm: device or resource busy
Failed to remove container (c34922906202): Error response from daemon: Unable to remove filesystem for c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26: remove /var/lib/docker/containers/c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26/shm: device or resource busy

Информация о моей версии Docker следующая:
Клиент:
Версия: 1.10.2
Версия API: 1.22
Версия Go: go1.5.3
Git commit: c3959b1
Построен: Пн 22 фев, 21:37:01 2016
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.10.2
Версия API: 1.22
Версия Go: go1.5.3
Git commit: c3959b1
Построен: Пн 22 фев, 21:37:01 2016
ОС / Arch: Linux / amd64

Следует отметить, что я столкнулся с этой проблемой совсем недавно. Я работаю с Docker около года.

Привет,
Просто хотел упомянуть, что после перезапуска компьютера я обнаружил, что ранее не удаленные контейнеры были удалены. Это действительно решает проблему, но все же будет раздражать накопление контейнеров и необходимость всегда перезагружать ОС.

@chirangaalwis +1. Вы замечали, что это происходит после того, как контейнер проработал какое-то время, или это происходит сразу после запуска контейнера?

Привет,
Насколько я помню, я испытал это спустя значительное время с момента запуска контейнеров. Не спустя очень долгое время, если быть точным.

Кстати, было бы неплохо, если бы кто-нибудь мог подробно объяснить причину этой проблемы. Я относительно новичок в концепции контейнеризации.

@chirangaalwis , вы проверили эту проблему: https://github.com/docker/docker/issues/17902 Похоже, это может быть специфично для версии ядра. Я собираюсь обновить ядро ​​на машине, на которой возникла проблема, на следующий день или около того, и посмотрю, решит ли это ее.

+1. Да, похоже, даже у меня ядро ​​3.13. Да, я также проверю это, карты с тем, что я сообщил.

@chirangaalwis @kabobbob ... Я использую RHEL 7.2 и ядро ​​3.10.

[root<strong i="7">@pe2enpmas301</strong> npmo-server]# uname -a
Linux pe2enpmas301.corp.intuit.net 3.10.0-327.3.1.el7.x86_64 #1 SMP Fri Nov 20 05:40:26 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

При остановке и запуске контейнеров с помощью docker-compose я постоянно получаю эту ошибку ....

Recreating npmoserver_policyfollower_1
ERROR: Driver devicemapper failed to remove root filesystem 3bb07965510f2c398c0fc99c3e0ce4696914f710efabc47f2df19ecf85725021: Device is Busy

Единственный обходной путь - остановиться и подождать пару секунд, прежде чем повторить попытку. Проблема в том, что перезапуск не гарантирован. Иногда я пытаюсь перезагрузить несколько раз.

@chirangaalwis @marcellodesales Я смог обновить сервер до ядра 3.16 и попытался остановить контейнер и запустить rm. Казалось, все работает хорошо. Нужно будет поработать и посмотреть, решена ли проблема.

@kabobbob, пожалуйста, сообщите через пару дней, если это сработало лучше ... Я попробую обновить среду,

Если бы это было на rhel 7.2 - обновление yum && systemctl исправило это.

Использовал прямой LVM и Docker версии 1.9.1

У меня тоже такая проблема. Моя установка: Ubuntu 14.04, обновлено до ядра «3.19.0-58-generic # 64 ~ 14.04.1-Ubuntu». Докер версии 1.11.0, сборка 4dc5990. "docker-compose версия 1.7.0, сборка 0d7bf73".

Когда docker-compose up -d перезапускает контейнер из-за нового образа, он часто не может удалить остановленный контейнер.

Только перезагрузка поможет запустить контейнер. Тогда проблема не воспроизводима на 100%, но это происходит очень часто. Поэтому я вынужден часто перезагружать хост-машину :-(

$ docker rm 5435d816c9a3_dockercomposeui_docker-compose-ui_1
Error response from daemon: Driver devicemapper failed to remove root filesystem 5435d816c9a35c63a5a636dc56b7d9052f1681ae21d604127b1685dab3848404: Device is Busy

и

# docker ps -a | grep dockercomposeui
5435d816c9a3        c695fdb43f7a                          "/env/bin/python /app"   2 days ago          Dead                                                                                                                   5435d816c9a3_dockercomposeui_docker-compose-ui_1

@dsteinkopf Вы сталкивались с этим после обновления с 1.10 до 1.11? По какой причине вы используете devicemapper в Ubuntu? В целом, значение по умолчанию (aufs) должно дать вам лучшую производительность. В ядре 3.19 оверлей может быть даже лучшим выбором

Нет, проблема уже существовала с использованием docker 1.10 и со стандартным ядром ubuntu 14.04 (я думаю, ~ 3.10) и с использованием aufs. Затем я обновил (шаг за шагом) драйвер хранилища, ядро ​​и докер. Никаких значительных изменений в испытанной проблеме ...

Как думаете, стоит ли попробовать оверлей по этой проблеме? (В моем случае производительность не является большой проблемой.)

@thaJeztah Я никогда не видел этой проблемы раньше и с тех пор

Вы столкнулись с этим после обновления с 1.10 до 1.11

У меня такая проблема :(

Все еще получил это
RHEL 7.2 ядро-3.10.0-327.el7.x86_64
Докер версии 1.9.1, сборка 78ee77d / 1.9.1
устройство-сопоставитель-библиотеки-1.02.107-5.el7_2.1.x86_64

Также возникла проблема:

docker rm agent4 Error response from daemon: Driver aufs failed to remove root filesystem 16a3129667975c411d0084b38ba512761b64eaa7853f3452a7f8e4f2898d1175: rename /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a-removing: device or resource busy

версия докера

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

информация о докере

Containers: 9
 Running: 8
 Paused: 0
 Stopped: 1
Images: 80
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 193
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.45 GiB
Name: chell
ID: BXX3:THMK:SWD4:FP35:JPVM:3MV4:XJ7S:DREY:O6XO:XYUV:RHXO:KUBS
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

uname -a

Linux chell 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

Это смесь разных проблем. Я думаю, нам нужно закрыть это. Ни один из последних зарегистрированных случаев не похож на ОП.

@guenhter Я подозреваю, что это связано с другой проблемой с монтированием / var / run в контейнер (любой другой контейнер на вашем хосте) или с монтированием / var / lib / docker

@guenhter Для протокола # 21969

Кроме того, многие из проблем, связанных с ошибками типа «устройство или ресурс занят» до версии 1.11, скорее всего, были вызваны убийством демона (некрасиво) и последующим его запуском.
Это приводит к сбросу счетчиков внутренних ссылок на монтирования драйверов хранилища на 0, в то время как сами монтирования остаются активными.
1.11 рассматривает этот случай.

Закрытие по причинам, указанным выше.

Извините, я не уверен, что понимаю это. Что вы имеете в виду под «Ни один из последних зарегистрированных случаев не похож на ОП»?
Что мне (и другим людям, испытывающим эту проблему) делать? Открыть другое дело?

@dsteinkopf Да, с максимально возможной детализацией (создание файлов, журналы демонов и т. д.).

Привет, чтобы отметить проблему, которую я указал ранее, я обновил свою версию ядра до 4.4.0-21-generic, а информация о версии докера выглядит следующим образом:
Клиент:
Версия: 1.11.0
Версия API: 1.23
Версия Go: go1.5.4
Git commit: 4dc5990
Построен: 13 апр, среда, 18:38:59, 2016
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.11.0
Версия API: 1.23
Версия Go: go1.5.4
Git commit: 4dc5990
Построен: 13 апр, среда, 18:38:59, 2016
ОС / Arch: Linux / amd64

Проблема, о которой сообщалось ранее, похоже, больше не возникает. Долгое время использовал Docker, обновляя версии ядра, и, похоже, он остановился.

Нашел обходной путь для проблемы, по крайней мере, при использовании с docker-compose см. Https://github.com/docker/docker/issues/3786#issuecomment -221601065

Та же проблема с контейнером, который не перезапускается.

Ubuntu 14.04
Ядро: 3.13.0-24-generic
Версия Докера:

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Ошибка:

Error response from daemon: Driver aufs failed to remove root filesystem 
802f3a6eb28f8f16bf8452675a389b1d8bf755e59c827d50bec9372420f4194a: 
rename /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f-removing: 
device or resource busy

Размонтировать не удается:

umount: /var/lib/docker/devicemapper
/mnt/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f is not mounted 
(according to mtab)

Для нас это по-прежнему проблема (с использованием 1.11.2 в Ubuntu 14.04.4 LTS (с KVM) (3.13.0-88-generic)).

Есть ли открытый билет, на который я могу подписаться, чтобы получать обновления?

@GameScripting См. № 21704

Linux zk1 3.10.0-327.28.3.el7.x86_64 (centos 7)
Докер версии 1.12.1, сборка 23cf638

Ответ от демона об ошибке: Driver devicemapper не удалось удалить корневую файловую систему 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901: devicemapper: Ошибка при запуске DeleteDevice dm_task_run failed

Просто столкнулся с этим. /etc/init.d/docker restart помогло, я рад, что этого не было на производственной машине ... 😢

$ docker --version
Docker version 1.11.1, build 5604cbe

Все еще получаю это тоже

$ docker --version
Docker version 1.12.2, build bb80604

Та же проблема наблюдается во многих версиях Docker. Я использую docker-compose для воссоздания контейнеров. Иногда это работает чисто, иногда нет. Перезапуск демона докера или перезагрузка сервера очищает плохой контейнер.

Arch Linux; Контейнеры devicemapper на ext4 FS.

$ docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64
$ docker info
Containers: 24
 Running: 22
 Paused: 0
 Stopped: 2
Images: 56
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-8:3-13500430-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 9.394 GB
 Data Space Total: 107.4 GB
 Data Space Available: 78.15 GB
 Metadata Space Used: 24.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.123 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.135 (2016-09-26)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.7.2-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 30.85 GiB
Name: omega
ID: IR7W:NSNN:F2B3:YP32:YTQJ:OFEB:2XLK:HHCK:HJ33:5K3O:KEHI:SDUB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8
$ df -T
Filesystem     Type     1K-blocks      Used Available Use% Mounted on
dev            devtmpfs  16169500         0  16169500   0% /dev
run            tmpfs     16173076      2712  16170364   1% /run
/dev/sda3      ext4     447260560 371064976  53453004  88% /
tmpfs          tmpfs     16173076         0  16173076   0% /dev/shm
tmpfs          tmpfs     16173076         0  16173076   0% /sys/fs/cgroup
tmpfs          tmpfs     16173076      1144  16171932   1% /tmp
/dev/sda1      ext4        289293     45063    224774  17% /boot
tmpfs          tmpfs      3234612         8   3234604   1% /run/user/1000
/dev/sdb2      ext4     403042160  15056296 367489480   4% /run/media/ivan/backup
/dev/sda4      ext4     480580312 320608988 135536228  71% /run/media/ivan/ARCHIVES
/dev/sdb3      ext4     225472980   1473948 212522604   1% /run/media/ivan/data

Если это поможет ...

Я считаю, что здесь у меня такая же / похожая проблема. Если развернуть службу с помощью compose up -d, а затем обновить имя изображения на другое в compose.yaml и выполнить другое compose up -d, compose завершится с ошибкой вокруг devicemapper:

ошибка
ОШИБКА: для <> Драйвер devicemapper не смог удалить корневую файловую систему 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: устройство занято

Информация о версии:
версия докера
Клиент:
Версия: 1.12.1
Версия API: 1.24
Версия Go: go1.6.3
Git commit: 23cf638
Построено:
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.12.1
Версия API: 1.24
Версия Go: go1.6.3
Git commit: 23cf638
Построен:
ОС / Arch: Linux / amd64

В качестве временного обходного пути я добавил docker-compose down --rmi all перед повторным запуском up.

У меня такая же проблема в версии Docker: 1.12.3

Я почти уверен, что остальные люди, столкнувшиеся с этой проблемой, связаны с # 27381.

Я вижу это в докере 1.12.3 на CentOs 7

dc2-elk-02: / корень / постановка / ls-helper $ docker --version
Докер версии 1.12.3, сборка 6b644ec
dc2-elk-02: / корень / стадия / ls-helper $ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64 # 1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / корень / стадия / ls-helper $ docker rm ls-helper
Ответ демона об ошибке: драйверу devicemapper не удалось удалить корневую файловую систему e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: устройство занято

PS Я не использую docker compose.

Укушен после того, как хост вышел из-под диска.
Зависает любая команда, влияющая на точку монтирования (включая «docker ps», «sync», «ls", ...)

У меня была аналогичная проблема, я видел эти ошибки в моем файле / var / log / syslog:
Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627417173+05:30" level=error msg="Failed to load container mount 00d7b9d64ff6c465276e67f5a5e3642ebacd9616c7602d4361b3a7fab038510a: mount does not exist" Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627816711+05:30" level=error msg="Failed to load container mount fb108b942f8ed87a9e1affb6480ed477a8f5f823b2639e36348cde4a97924c5e: mount does not exist"
Я попытался найти точку монтирования в /var/lib/docker/volumes но не нашел
наконец-то перезагрузите систему, проблема решена