Impossibile eseguire l'errore Docker del contenitore Docker causa l'errore del mapper

Question

Non riesco proprio a creare ed eseguire nuovi contenitori in Docker. Ma allo stesso tempo è possibile eseguire contenitori creati in precedenza.

Quando provo a fare qualcosa di simile:

[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 

Da 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 

stato dmsetup

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

ma sono molto di spazio libero su disco.

informazioni 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 

informazioni finestra mobile

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 

versione finestra mobile

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

Il seguente è per un sistema Fedora/RHEL, quindi avrai bisogno di regolare per Debian ...

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

Se non ci sono errori poi procedere con:

# 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

Quando la partizione di finestra mobile riempito e finestra mobile non sarebbe più avviarsi dopo il riavvio, ho incontrato questo:

# 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 

sono stato in grado di riparare con questa procedura:

# 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

Ho avuto lo stesso problema e non è stato in grado di risolverlo. Ho trovato qualcosa di promettente a: http://grokbase.com/t/gg/docker-user/1563fzdtm7/docker-docker-runs-out-of-space-when-trying-to-create-a-new-image 'Il driver di archiviazione docker predefinito alloca blocchi di memoria da 10 GB per le tue immagini . Passa a overlayfs ed evita tutto ciò. Nel comando che avvia il demone docker basta aggiungere "-s sovrapposizione" '

risolto il problema.

Answer 4

Ho combattuto questo problema con Debian 8.2. Ho avuto altri problemi perché eseguo un kernel 4.3.3 (il default è 3.16) con grsec.

Nonostante i problemi GRSEC (montaggio & chmod negato) sono riuscito a eseguire la finestra mobile e creare un'immagine e un contenitore.

Quindi, vorrei riavviare e la finestra mobile sarebbe solo sputare l'errore. mi sono imbattuto thin_check e quello che ho trovato è stato questo:

• metadati andava bene (io non uso una piscina sottile in questo momento in quanto finestra mobile continua a dirmi che la mia piscina sottile non è una piscina sottile ...)
• dati è stato danneggiato.

Provato per ripararlo ma si verifica un arresto anomalo di thin_restore.

Mi sono reso conto che: il daemon docker ... funzionava ma non può essere arrestato con systemctl stop docker.service. Si dice che il servizio viene arrestato, ma il demone è ancora in memoria (ps -elf | grep finestra mobile)

Per risolvere il problema ho dovuto cambiare le DOCKER_STORAGE_OPTIONS in/etc/default/finestra mobile

rm -rf /var/lib/docker 
reboot 

All'avvio, il servizio inizia. info docker

Mostra le informazioni come previsto. Costruito un'immagine. Riavviato, il servizio inizia nuovamente. Credo che in fondo il demone finestra mobile non può essere fermato e uccidendo con un:

kill <pid> 

Provoca il file di dati per essere danneggiato e quindi la somma di controllo non corrisponderà.

La linea di fondo è non combinare docker.service e daemon docker. Almeno su Debian/Ubuntu.

Answer 5

Nel nostro caso è sufficiente avviare e interrompere il servizio.