Nie można uruchomić kontenera Docker z powodu błędu mapera urządzeń

Question

Po prostu nie mogę już tworzyć i uruchamiać nowych kontenerów w Dockerze. Ale w tym samym czasie można uruchomić wcześniej utworzone pojemniki.

Kiedy próbuję zrobić coś takiego:

[user@host ~ ] docker run --name=fpm-5.3 debian:jessie 
2014/07/12 07:34:08 Error: Error running DeviceCreate (createSnapDevice) dm_task_run failed 

Od docker.log:

2014/07/12 05:57:11 POST /v1.12/containers/create?name=fpm-5.3 
[f56fcb6f] +job create(fpm-5.3) 
Error running DeviceCreate (createSnapDevice) dm_task_run failed 
[f56fcb6f] -job create(fpm-5.3) = ERR (1) 
[error] server.go:1025 Error: Error running DeviceCreate (createSnapDevice) dm_task_run failed 
[error] server.go:90 HTTP Error: statusCode=500 Error running DeviceCreate (createSnapDevice) dm_task_run failed 

Dmsetup stanu

docker-8:1-1210426-pool: 0 209715200 thin-pool 352 2510/524288 205173/1638400 - ro discard_passdown queue_if_no_space 

Ale są dużo wolnego miejsca na dysku.

informacji Dmsetup

Name:    docker-8:1-1210426-pool 
State:    ACTIVE 
Read Ahead:  256 
Tables present: LIVE 
Open count:  1 
Event number:  1 
Major, minor:  252, 0 
Number of targets: 1 

informacji doker

Containers: 4 
Images: 65 
Storage Driver: devicemapper 
Pool Name: docker-8:1-1210426-pool 
Data file: /var/lib/docker/devicemapper/devicemapper/data 
Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata 
Data Space Used: 12823.3 Mb 
Data Space Total: 102400.0 Mb 
Metadata Space Used: 9.9 Mb 
Metadata Space Total: 2048.0 Mb 
Execution Driver: native-0.2 
Kernel Version: 3.14.4 

wersja doker

Client version: 1.0.0 
Client API version: 1.12 
Go version (client): go1.2.2 
Git commit (client): 63fe64c 
Server version: 1.0.0 
Server API version: 1.12 
Go version (server): go1.2.2 
Git commit (server): 63fe64c 

Answer 1

Poniższy jest dla systemu Fedora/RHEL, więc trzeba dostosować do Debiana ...

# systemctl stop docker.service 
# thin_check /var/lib/docker/devicemapper/devicemapper/metadata 

Gdyby nie było żadnych błędów a następnie postępuj zgodnie ze wskazówkami:

# thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata 
# systemctl start docker.service 
# docker run --name=fpm-5.3 debian:jessie 

Answer 2

Kiedy partycja doker wypełniony i doker nie będzie już uruchomić po restarcie, natknąłem to:

# thin_check /var/lib/docker/devicemapper/devicemapper/metadata 
examining superblock 
examining devices tree 
    missing devices: [0, -] 
    bad checksum in btree node 
examining mapping tree 
    thin device 72 is missing mappings [137494, 137594] 
    bad checksum in btree node 
    thin device 72 is missing mappings [137721, -] 
    bad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree node 

udało mi się naprawić z tej procedury:

# thin_dump -r /var/lib/docker/devicemapper/devicemapper/metadata -o /tmp/metadata.xml 
# thin_restore -i /tmp/metadata.xml -o /var/lib/docker/devicemapper/devicemapper/metadata 

Answer 3

Miałem ten sam problem i nie mogłem go naprawić. Znalazłem coś obiecującego pod adresem: http://grokbase.com/t/gg/docker-user/1563fzdtm7/docker-docker-runs-out-of-space-when-trying-to-create-a-new-image 'Domyślny sterownik do magazynowania w Dockerze przydziela 10 GB bloków pamięci dla obrazów . Przejdź do overlayfs i unikaj tego całkowicie. W poleceniu, że uruchamia demona docker, po prostu dodaj "-s nakładki" "

naprawił to mój problem.

Answer 4

Walczyłem z tym problemem w Debianie 8.2. Miałem inne problemy, ponieważ uruchamiam jądro 4.3.3 (domyślnie 3.16) z grsec.

Mimo problemów z GRSEC (mount & chmod denied) udało mi się uruchomić okno dokowane i utworzyć obraz i kontener.

Następnie, uruchomiłbym się ponownie, a okno dokowane wyplułoby błąd. Pobiegłem thin_check i co znalazłem to:

• metadanych było w porządku (nie używam cienką basen teraz od doker ciągle mówi mi, że mój cienki basen nie jest cienka basen ...)
• dane zostały uszkodzone.

Próbowałem go naprawić, ale system thin_restore wywala.

Zrozumiałem, że: demon docker ... działał, ale nie można go zatrzymać za pomocą systemctl stop docker.service. Mówi, że usługa zostanie zatrzymana, ale demon wciąż jest w pamięci (ps -elf | grep doker)

Aby rozwiązać ten problem miałem zmienić DOCKER_STORAGE_OPTIONS w/etc/default/docker

rm -rf /var/lib/docker 
reboot 

Po uruchomieniu usługa się uruchamia. dokowanie info

Pokazuje informacje zgodnie z oczekiwaniami. Zbudowano obraz. Po ponownym uruchomieniu usługa znów zaczyna działać poprawnie. Myślę, że w zasadzie demon Robotnik nie może być zatrzymany i zabijając go z:

kill <pid> 

Powoduje, że plik danych jest uszkodzona i dlatego suma kontrolna nie będzie pasował.

Dolna linia nie miesza się z usługą docker.service i demonem docker. Przynajmniej na Debianie/Ubuntu.

Answer 5

W naszym przypadku wystarczy uruchomić i zatrzymać usługę.