Moby: Le mappeur de périphérique du pilote n'a pas réussi à supprimer le système de fichiers racine. Le périphérique est occupé

Est-ce que cela se produit avec n'importe quel conteneur? Qu'est-ce qui s'exécute dans le conteneur et quelles options utilisez-vous pour démarrer le conteneur ? (par exemple, utilisez-vous des répertoires montés par liaison, utilisez-vous docker exec pour démarrer des processus supplémentaires dans le conteneur ?)

Nous exécutons tous les conteneurs à peu près de la même manière et cela se produit de manière aléatoire sur l'un d'entre eux.
Nous n'utilisons pas docker exec , ne liez aucun répertoire.
Voici la configuration de l'un des conteneurs morts :

[
    {
        "Id": "ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535",
        "Created": "2016-10-13T09:14:52.069916456Z",
        "Path": "/run.sh",
        "Args": [],
        "State": {
            "Status": "dead",
            "Running": false,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": true,
            "Pid": 0,
            "ExitCode": 143,
            "Error": "",
            "StartedAt": "2016-10-13T18:05:50.839079884Z",
            "FinishedAt": "2016-10-14T01:49:22.133922284Z"
        },
        "Image": "sha256:df8....4f4",
        "ResolvConfPath": "/var/lib/docker/containers/ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535/hostname",
        "HostsPath": "/var/lib/docker/containers/ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535/hosts",
        "LogPath": "",
        "Name": "/d9a....43",
        "RestartCount": 0,
        "Driver": "devicemapper",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": [],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "fluentd",
                "Config": {
                    "fluentd-address": "127.0.0.1:24224",
                    "fluentd-async-connect": "true",
                    "labels": "app_id",
                    "tag": "docker.{{if (.ExtraAttributes nil).app_id}}{{(.ExtraAttributes nil).app_id}}{{else}}{{.Name}}{{end}}"
                }
            },
            "NetworkMode": "default",
            "PortBindings": {
                "3000/tcp": [
                    {
                        "HostIp": "127.0.0.2",
                        "HostPort": ""
                    }
                ]
            },
            "RestartPolicy": {
                "Name": "always",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "CapAdd": null,
            "CapDrop": null,
            "Dns": [],
            "DnsOptions": [],
            "DnsSearch": [],
            "ExtraHosts": [
                "mongodb:10.240.0.2"
            ],
            "GroupAdd": null,
            "IpcMode": "",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "CgroupParent": "mygroup/d9...43",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": null,
            "DiskQuota": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": -1,
            "OomKillDisable": false,
            "PidsLimit": 0,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0
        },
        "GraphDriver": {
            "Name": "devicemapper",
            "Data": {
                "DeviceId": "29459",
                "DeviceName": "docker-8:1-34634049-8e884a263c75cfb042ac02136461c8e8258cf693f0e4992991d5803e951b3dbb",
                "DeviceSize": "107374182400"
            }
        },
        "Mounts": [],
        "Config": {
            "Hostname": "ce2ea989895b",
            "Domainname": "",
            "User": "app",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "3000/tcp": {}
            },
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PORT=3000",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/run.sh"
            ],
            "Image": "eu.gcr.io/reg/d9...43:latest",
            "Volumes": null,
            "WorkingDir": "/data/app",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "app_id": "d9...43"
            }
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "65632062399b8f9f011fdebcd044432c45f068b74d24c48818912a21e8036c98",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": null,
            "SandboxKey": "/var/run/docker/netns/65632062399b",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "59d8aa11b92aaa8ad9da7f010e8689c158cad7d80ec4b9e4e4688778c49149e0",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": ""
                }
            }
        }
    }
]

Je viens de remarquer que cela se produit uniquement sur les serveurs avec ce système Backing Filesystem: ext4 fichiers
Le problème ne semble pas se produire sur les serveurs exécutant xfs comme système de fichiers de sauvegarde.

@ceecko merci, c'est intéressant

@rhvgoyal est-ce un problème connu de votre côté ?

Cela nous frappe durement en production :/ Des conseils sur la façon de supprimer les conteneurs morts ?

@thaJeztah Étrange que cela ne se produise qu'avec ext4 et non xfs. Je ne suis pas au courant d'une telle chose.

En général, les gens ont signalé que l'appareil était occupé et il peut y avoir tellement de raisons à cela.

@ceeko assurez-vous tout d'abord que le démon docker s'exécute dans son propre espace de noms de montage esclave et non dans l'espace de noms de montage hôte. Ainsi, les points de montage ne fuient pas et les chances d'obtenir de telles erreurs sont moindres. Si vous utilisez un docker piloté par systemd, il devrait y avoir un fichier d'unité docker et il devrait avoir MountFlags=slave.

@rhvgoyal Le MountFlags=slave semble résoudre le problème jusqu'à présent. Les conteneurs créés avant la modification posent toujours problème, mais les nouveaux conteneurs ne semblent pas encore déclencher l'erreur. Je vous contacterai au cas où quelque chose changerait.

Au fait, il peut être utile de mettre à jour la documentation du pilote de stockage pour le recommander comme meilleure pratique en production, car je n'ai trouvé aucune référence.

Merci de votre aide.

Cela a été changé il y a quelque temps; https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68 (https://github.com/docker/docker/pull/22806), selon la discussion, cette suppression différée peut être un problème si différé pas activé; https://github.com/docker/docker/pull/22806#issuecomment-220043409

Doit-on revenir à la valeur par défaut ? @rhvgoyal

@thaJeztah Je pense que ce pourrait être une bonne idée de revenir par défaut à MountFlags=slave. Nous l'avons fait.

Idéalement, les fonctionnalités de suppression différée et de suppression différée auraient dû s'occuper de cela et il n'était pas nécessaire d'utiliser MountFlags=slave. Mais la suppression différée seule n'est pas suffisante. Les anciens noyaux manquent d'une fonctionnalité permettant de supprimer un répertoire d'un espace de noms de montage même s'il est monté dans un espace de noms de montage différent. Et c'est l'une des raisons pour lesquelles le retrait des conteneurs peut échouer.

Donc, jusqu'à ce que les anciens noyaux offrent cette fonctionnalité, il peut être judicieux d'exécuter le démon docker dans un espace de noms de montage esclave.

@rhvgoyal les erreurs ont recommencé à apparaître même avec MountFlags=slave . Nous allons essayer la suppression différée et la suppression et nous vous répondrons.

Nous venons de rencontrer la même erreur sur xfs également.
Voici les informations sur le docker

Containers: 52
 Running: 52
 Paused: 0
 Stopped: 0
Images: 9
Server Version: 1.12.2
Storage Driver: devicemapper
 Pool Name: data-docker_thin
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 13 GB
 Data Space Total: 107.1 GB
 Data Space Available: 94.07 GB
 Metadata Space Used: 19.19 MB
 Metadata Space Total: 268.4 MB
 Metadata Space Available: 249.2 MB
 Thin Pool Minimum Free Space: 10.71 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host overlay bridge null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.10.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.389 GiB
Name: ip-172-31-25-29.eu-west-1.compute.internal
ID: ZUTN:S7TL:6JRZ:HG52:LDLZ:VR5Q:RWVV:IP7E:HOQ4:R55X:Z7AI:P63R
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8

Je confirme que l'erreur se produit toujours sur 1.12.2 même avec MountFlags=slave et dm.use_deferred_deletion=true et dm.use_deferred_removal=true même si moins fréquemment qu'avant.

Voici plus d'informations dans les journaux concernant 1 conteneur qui n'a pas pu être supprimé :

libcontainerd: container 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543 restart canceled
error locating sandbox id c9272d4830ba45e03efda777a14a4b5f7f94138997952f2ec1ba1a43b2c4e1c5: sandbox c9272d4830ba45e03efda777a14a4b5f7f94138997952f2ec1ba1a43b2c4e1c5 not found
failed to cleanup ipc mounts:\nfailed to umount /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: invalid argument
devmapper: Error unmounting device ed06c57080b8a8f25dc83d4afabaccb26d72009dad23a8e87310b873c226b905: invalid argument
Error unmounting container 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543: invalid argument
Handler for DELETE /containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543 returned error: Unable to remove filesystem for 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543: remove /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: device or resource busy

Le message suivant suggère que la suppression du répertoire a échoué.

remove /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: device or resource busy

Et dans un noyau plus ancien, cela peut échouer car le répertoire est monté dans un autre espace de noms de montage. Si vous désactivez la fonction deferred deletion , ce message cessera de s'afficher. Mais cela deviendra un autre message d'erreur.

Le cœur du problème ici est que le conteneur est toujours en cours d'exécution ou que certains de ses points de montage ont fui dans d'autres espaces de noms de montage. Et si nous pouvons déterminer dans quel espace de noms de montage il a fui et comment il y est arrivé, nous pourrions essayer de le réparer.

Une fois que vous rencontrez ce problème, vous pouvez essayer de faire find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543"

Et puis voyez quels pids ont des montures liées à des conteneurs qui ont fui dedans. Et ça peut donner une idée.

J'ai essayé quatre conteneurs qui sont tous morts et ne peuvent pas être supprimés car l'appareil est occupé et n'a rien obtenu :/

# find /proc/*/mounts | xargs grep -E "b3070ef60def|62777ad2994f|923a6d20506d|f3e079a9721c"
grep: /proc/9659/mounts: No such file or directory

Maintenant, j'obtiens en fait un message d'erreur légèrement différent :

# docker rm b3070ef60def
Error response from daemon: Driver devicemapper failed to remove root filesystem b3070ef60deffc0e496631ed6e058c4569d6233bb6947b27072a70c663d9e579: remove /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd: device or resource busy

Même chose. ce répertoire ne peut pas être supprimé car il est monté dans un autre espace de noms de montage. Essayez de rechercher dans /proc//mounts et grep pour cet identifiant 527ae5 et voyez quel pid voit ce point de montage. Nous devons comprendre dans votre configuration pourquoi le point de montage rootfs du conteneur fuit dans un autre espace de noms de montage.

Nous y voilà:

# find /proc/*/mounts | xargs grep -E "527ae5"
grep: /proc/10080/mounts: No such file or directory
/proc/15890/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/23584/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/31591/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/4194/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/4700/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/4701/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/8858/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/8859/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0

nginx     4194  0.0  0.0  55592 10520 ?        S    11:55   0:06 nginx: worker process is shutting down
nginx     4700  2.3  0.0  55804 10792 ?        S    11:58   3:52 nginx: worker process is shutting down
nginx     4701  1.8  0.0  55800 10784 ?        S    11:58   3:04 nginx: worker process is shutting down
nginx     8858  2.4  0.0  55560 10720 ?        S    14:05   0:59 nginx: worker process
nginx     8859  3.1  0.0  55560 10700 ?        S    14:05   1:15 nginx: worker process
root     15890  0.0  0.0  55004  9524 ?        Ss   Oct29   0:05 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    23584  0.0  0.0  55576 10452 ?        S    09:17   0:00 nginx: worker process is shutting down
nginx    31591  0.9  0.0  63448 18820 ?        S    09:46   2:53 nginx: worker process is shutting down

à quels processus ces pid sont-ils mappés ? Essayez cat /proc/<pid>/comm ou ps -eaf | grep <pid>

Ce sont tous les processus de travail nginx qui s'arrêtent après un rechargement de la configuration (voir le commentaire modifié ci-dessus). Je me demande pourquoi ils bloquent les montages puisque les conteneurs ne lient aucun volume.

Donc, le processus nginx s'exécute dans un autre conteneur ? Ou il s'exécute sur l'hôte ?

Pouvez-vous faire suivant.

• ls -l /proc/<docker-daemon-pid>/ns/mnt
• ls -l /proc/<nginx-pid>/ns/mnt
• Exécutez un shell bash sur l'hôte et exécutez ls -l /proc/$$/ns/mnt

Et coller la sortie. ici.

nginx s'exécute sur l'hôte.

docker-pid

# ls -l /proc/13665/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:01 /proc/13665/ns/mnt -> mnt:[4026531840]

nginx-pid

# ls -l /proc/15890/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:01 /proc/15890/ns/mnt -> mnt:[4026533289]

ls -l /proc/$$/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:02 /proc/10063/ns/mnt -> mnt:[4026531840]

Votre docker-pid et votre hôte semblent tous les deux partager le même espace de noms de montage. Et cela signifie que le démon docker s'exécute dans l'espace de noms de montage hôte. Et cela signifie probablement que nginx a démarré à un moment donné après le démarrage du conteneur et qu'il semble s'exécuter dans son propre espace de noms de montage. Et à ce moment-là, les points de montage ont fui dans l'espace de noms de montage nginx et cela empêche la suppression du conteneur.

Veuillez vous assurer que MountFlags=slave fonctionne pour vous. Une fois que cela fonctionne, /proc//ns/mnt donnera une sortie différente pour le démon docker et le shell bash s'exécutant dans l'espace de noms de montage hôte.

Tu as raison. Cet hôte n'a pas encore configuré le MountFlags=slave .
Un hôte différent l'a fait et il y avait toujours des conteneurs morts. Je les ai tous supprimés manuellement maintenant, mais ils ont été créés avec MountFlags=slave .

J'attendrai que la situation se répète et posterai une mise à jour ici. Merci.

Maintenant, la situation est la suivante - nous utilisons MountFlags=slave et la suppression et la suppression différées et parfois l'API distante renvoie une erreur indiquant que le périphérique est occupé et ne peut pas être supprimé. Cependant, lorsque docker rm container est appelé juste après l'erreur, il supprime parfaitement le conteneur.

Le problème est réapparu.

docker

# ll /proc/16441/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  4 23:05 /proc/16441/ns/mnt -> mnt:[4026534781]

nginx

# ll /proc/15890/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:01 /proc/15890/ns/mnt -> mnt:[4026533289]

# ll /proc/$$/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  4 23:06 /proc/22029/ns/mnt -> mnt:[4026531840]

# find /proc/*/mounts | xargs grep -E "a2388cf8d19a"
/proc/11528/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/12918/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/1335/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/14853/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/1821/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/22241/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/22406/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/22618/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
grep: /proc/22768/mounts: No such file or directory
/proc/22771/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/23601/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24108/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24405/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24614/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24817/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25116/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25277/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25549/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25779/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26036/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26211/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26369/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26638/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26926/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27142/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27301/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27438/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27622/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27770/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27929/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28146/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28309/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28446/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28634/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28805/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28961/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29097/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/2909/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29260/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29399/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29540/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29653/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29675/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29831/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30040/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30156/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30326/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30500/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30619/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30772/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30916/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31077/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31252/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31515/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31839/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/32036/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/32137/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/3470/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/5628/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/5835/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/8076/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0

Processus de la commande précédente

  PID TTY      STAT   TIME COMMAND
 1335 ?        Sl     0:00 docker-containerd-shim 9a678ecbd9334230d61a0e305cbbb50e3e5207e283decc2d570d787d98f8d930 /var/run/docker/libcontainerd/9a678ecbd9334230d61a0e305cbbb50e3e5207e283decc2d570d787d98f8d930 docker-runc
 1821 ?        Sl     0:00 docker-containerd-shim 97f0a040c0ebe15d7527a54481d8946e87f1ec0681466108fd8356789de0232b /var/run/docker/libcontainerd/97f0a040c0ebe15d7527a54481d8946e87f1ec0681466108fd8356789de0232b docker-runc
 2909 ?        Sl     0:00 docker-containerd-shim ef2e6a22e5ea5f221409ff8888ac976bd9b23633fab13b6968253104424a781f /var/run/docker/libcontainerd/ef2e6a22e5ea5f221409ff8888ac976bd9b23633fab13b6968253104424a781f docker-runc
 3470 ?        Sl     0:00 docker-containerd-shim 24b6918ce273a82100a1c6bae711554340bc60ff965527456130bd2fabf0ca6f /var/run/docker/libcontainerd/24b6918ce273a82100a1c6bae711554340bc60ff965527456130bd2fabf0ca6f docker-runc
 5628 ?        Sl     0:00 docker-containerd-shim 9561cbe2f0133119e2749d09e5db3f6473e77830a7981c1171849fe403d73973 /var/run/docker/libcontainerd/9561cbe2f0133119e2749d09e5db3f6473e77830a7981c1171849fe403d73973 docker-runc
 5835 ?        Sl     0:00 docker-containerd-shim a5afb5ab32c2396cdddd24390f94b01f597850012ad9731d6d47db9708567b24 /var/run/docker/libcontainerd/a5afb5ab32c2396cdddd24390f94b01f597850012ad9731d6d47db9708567b24 docker-runc
 8076 ?        Sl     0:00 docker-containerd-shim 20cca8e6ec26364aa4eb9733172c7168052947d5e204d302034b2d14fd659302 /var/run/docker/libcontainerd/20cca8e6ec26364aa4eb9733172c7168052947d5e204d302034b2d14fd659302 docker-runc
11528 ?        Sl     0:00 docker-containerd-shim f7584de190086d41da71235a6ce2516cbccb8ac0fff9f71b03d405af9478660f /var/run/docker/libcontainerd/f7584de190086d41da71235a6ce2516cbccb8ac0fff9f71b03d405af9478660f docker-runc
12918 ?        Sl     0:00 docker-containerd-shim 9ada39a06c5e1351df30dde993adcd048f8bd7984af2b412b8f3339f037c8847 /var/run/docker/libcontainerd/9ada39a06c5e1351df30dde993adcd048f8bd7984af2b412b8f3339f037c8847 docker-runc
14853 ?        Sl     0:00 docker-containerd-shim 4d05a794e0be9e710b804f5a7df22e2dd268083b3d7d957daae6f017c1c8fb67 /var/run/docker/libcontainerd/4d05a794e0be9e710b804f5a7df22e2dd268083b3d7d957daae6f017c1c8fb67 docker-runc
22241 ?        Sl     0:00 docker-containerd-shim ce81b6b51fcbf1163491381c790fc944b54adf3333f82d75281bc746b81ccd47 /var/run/docker/libcontainerd/ce81b6b51fcbf1163491381c790fc944b54adf3333f82d75281bc746b81ccd47 docker-runc
22406 ?        Sl     0:00 docker-containerd-shim 519e5531104278559d95f351e2212b04b06f44cbd1e05336cd306b9a958c8874 /var/run/docker/libcontainerd/519e5531104278559d95f351e2212b04b06f44cbd1e05336cd306b9a958c8874 docker-runc
22618 ?        Sl     0:00 docker-containerd-shim 869b356e7838ef3c0200864c58a89a22c812574a60da535eb2107a5da1d07a65 /var/run/docker/libcontainerd/869b356e7838ef3c0200864c58a89a22c812574a60da535eb2107a5da1d07a65 docker-runc
22771 ?        Sl     0:00 docker-containerd-shim 63f0816e72d4be4ed79fe2c31794876b1b3ab7a300ca69497a8bddbd8cf8953f /var/run/docker/libcontainerd/63f0816e72d4be4ed79fe2c31794876b1b3ab7a300ca69497a8bddbd8cf8953f docker-runc
23601 ?        Sl     0:00 docker-containerd-shim 9943b9930cb4803666caf5499dfb0753c36193efe0285f2ae697be63c6122003 /var/run/docker/libcontainerd/9943b9930cb4803666caf5499dfb0753c36193efe0285f2ae697be63c6122003 docker-runc
24108 ?        Sl     0:00 docker-containerd-shim 21af7db24bbd1679f48ae3cf0d022535c208c63dc42a274dd54e3cfcb90b9737 /var/run/docker/libcontainerd/21af7db24bbd1679f48ae3cf0d022535c208c63dc42a274dd54e3cfcb90b9737 docker-runc
24405 ?        Sl     0:00 docker-containerd-shim 0dccc5141be2367de2601d83020f7f4c27762d4c8e986b4b100a4bce12fc2f5a /var/run/docker/libcontainerd/0dccc5141be2367de2601d83020f7f4c27762d4c8e986b4b100a4bce12fc2f5a docker-runc
24614 ?        Sl     0:00 docker-containerd-shim e1023b528f8b2a1889c0fc360c0d1738a15be0bd53e0722920a9abb5ecc2c538 /var/run/docker/libcontainerd/e1023b528f8b2a1889c0fc360c0d1738a15be0bd53e0722920a9abb5ecc2c538 docker-runc
24817 ?        Sl     0:00 docker-containerd-shim 2106fe528147306e768b01b03ef7f10c53536ad4aaee6a628608c9c5bbf9494c /var/run/docker/libcontainerd/2106fe528147306e768b01b03ef7f10c53536ad4aaee6a628608c9c5bbf9494c docker-runc
25116 ?        Sl     0:00 docker-containerd-shim 1b9623bf34b5030d47faf21dee6462478d6d346327af0b4c96e6ccae4c880368 /var/run/docker/libcontainerd/1b9623bf34b5030d47faf21dee6462478d6d346327af0b4c96e6ccae4c880368 docker-runc
25277 ?        Sl     0:00 docker-containerd-shim 6662486b063f530a446602eed47811443eb737151b404c0d253bf54df9e6b93f /var/run/docker/libcontainerd/6662486b063f530a446602eed47811443eb737151b404c0d253bf54df9e6b93f docker-runc
25549 ?        Sl     0:05 docker-containerd-shim f6e3e14362455f38d6abfdeb106f280151ee3f12dc9d2808c774dd3d2cd3e828 /var/run/docker/libcontainerd/f6e3e14362455f38d6abfdeb106f280151ee3f12dc9d2808c774dd3d2cd3e828 docker-runc
25779 ?        Sl     0:00 docker-containerd-shim 144fded452cd9a0bdbcdf72890aa400eadb65e434038373e2ddfc1f4e28a1279 /var/run/docker/libcontainerd/144fded452cd9a0bdbcdf72890aa400eadb65e434038373e2ddfc1f4e28a1279 docker-runc
26036 ?        Sl     0:00 docker-containerd-shim e076f6cfc4fcd04a9a4fa6aecf37fe244d6d84e200380b6ef4a1e0a79575e952 /var/run/docker/libcontainerd/e076f6cfc4fcd04a9a4fa6aecf37fe244d6d84e200380b6ef4a1e0a79575e952 docker-runc
26211 ?        Sl     0:00 docker-containerd-shim 65bea267b22c9a6efe58ea9d7339986b01e7f67c095aa1451768de5114a5b027 /var/run/docker/libcontainerd/65bea267b22c9a6efe58ea9d7339986b01e7f67c095aa1451768de5114a5b027 docker-runc
26369 ?        Sl     0:00 docker-containerd-shim 390bc07f95b460220bda115aad2f247b33f50c81f7bd2b3d1a20e1696b95511b /var/run/docker/libcontainerd/390bc07f95b460220bda115aad2f247b33f50c81f7bd2b3d1a20e1696b95511b docker-runc
26638 ?        Sl     0:00 docker-containerd-shim b6d86f96d33260673b2e072419f08578716582578015a30e4f23d4e481a55809 /var/run/docker/libcontainerd/b6d86f96d33260673b2e072419f08578716582578015a30e4f23d4e481a55809 docker-runc
26926 ?        Sl     0:00 docker-containerd-shim 337ec28dd75f2f5bc2cfa813504d35a8c148777c7f246f8af5d792c36f3453ae /var/run/docker/libcontainerd/337ec28dd75f2f5bc2cfa813504d35a8c148777c7f246f8af5d792c36f3453ae docker-runc
27142 ?        Sl     0:00 docker-containerd-shim ba2216d6b46d7b57493734b093bc153823fb80a48ef4b91d0d1c660ee9adc519 /var/run/docker/libcontainerd/ba2216d6b46d7b57493734b093bc153823fb80a48ef4b91d0d1c660ee9adc519 docker-runc
27301 ?        Sl     0:00 docker-containerd-shim 520f66841a97b2545784b29ea3bc7a22a58d97987c404e1d99314da75307d279 /var/run/docker/libcontainerd/520f66841a97b2545784b29ea3bc7a22a58d97987c404e1d99314da75307d279 docker-runc
27438 ?        Sl     0:00 docker-containerd-shim 0908466da160ed739d74d675e1a6e04d85da0caa2216c739c0e218e75219dc3e /var/run/docker/libcontainerd/0908466da160ed739d74d675e1a6e04d85da0caa2216c739c0e218e75219dc3e docker-runc
27622 ?        Sl     0:00 docker-containerd-shim e627ef7439b405376ac4cf58702241406e3c8b9fbe76694a9593c6f96b4e5925 /var/run/docker/libcontainerd/e627ef7439b405376ac4cf58702241406e3c8b9fbe76694a9593c6f96b4e5925 docker-runc
27770 ?        Sl     0:00 docker-containerd-shim 0b6275f8f1d8277ac39c723825e7b830e0cf852c44696074a279227402753827 /var/run/docker/libcontainerd/0b6275f8f1d8277ac39c723825e7b830e0cf852c44696074a279227402753827 docker-runc
27929 ?        Sl     0:00 docker-containerd-shim fcf647fbe0fe024cc4c352a2395d8d315d647aeda7f75a2f9d42826eca3dee58 /var/run/docker/libcontainerd/fcf647fbe0fe024cc4c352a2395d8d315d647aeda7f75a2f9d42826eca3dee58 docker-runc
28146 ?        Sl     0:00 docker-containerd-shim 19f020044a3e600aa554a7ab00264155206e8791a7002f5616b397745b2c6405 /var/run/docker/libcontainerd/19f020044a3e600aa554a7ab00264155206e8791a7002f5616b397745b2c6405 docker-runc
28309 ?        Sl     0:00 docker-containerd-shim 3f6a5b9136df8169d3d1e1eb104bda6f4baf32ca5a2bc35ddaeea4a3a0bf774a /var/run/docker/libcontainerd/3f6a5b9136df8169d3d1e1eb104bda6f4baf32ca5a2bc35ddaeea4a3a0bf774a docker-runc
28446 ?        Sl     0:00 docker-containerd-shim f1ede5511531d05ab9eb86612ed239446a4b3acefe273ee65474b4a4c1d462e2 /var/run/docker/libcontainerd/f1ede5511531d05ab9eb86612ed239446a4b3acefe273ee65474b4a4c1d462e2 docker-runc
28634 ?        Sl     0:00 docker-containerd-shim 7485d577ec2e707e1151a73132ceba7db5c0509c1ffbaf750515e0228b2ffa33 /var/run/docker/libcontainerd/7485d577ec2e707e1151a73132ceba7db5c0509c1ffbaf750515e0228b2ffa33 docker-runc
28805 ?        Sl     0:00 docker-containerd-shim e5afd9eccb217e16f0494f71504d167ace8377498ce6141e2eaf96de71c74233 /var/run/docker/libcontainerd/e5afd9eccb217e16f0494f71504d167ace8377498ce6141e2eaf96de71c74233 docker-runc
28961 ?        Sl     0:00 docker-containerd-shim bd62214b90fab46a92893a15e06d5e2744659d61d422776ce9b395e56bb0e774 /var/run/docker/libcontainerd/bd62214b90fab46a92893a15e06d5e2744659d61d422776ce9b395e56bb0e774 docker-runc
29097 ?        Sl     0:00 docker-containerd-shim 81db13c46756851006d2f0b0393e37590bac228a3d958a12cc9f6c86d5992253 /var/run/docker/libcontainerd/81db13c46756851006d2f0b0393e37590bac228a3d958a12cc9f6c86d5992253 docker-runc
29260 ?        Sl     0:00 docker-containerd-shim 188d2c3a98cc1d65a88daeb17dacca7fca978831a9292b7225e60f7443096114 /var/run/docker/libcontainerd/188d2c3a98cc1d65a88daeb17dacca7fca978831a9292b7225e60f7443096114 docker-runc
29399 ?        Sl     0:00 docker-containerd-shim 1dc12f09be24722a18057072ac5a0b2b74324e13de051f213e1966c1d31e1348 /var/run/docker/libcontainerd/1dc12f09be24722a18057072ac5a0b2b74324e13de051f213e1966c1d31e1348 docker-runc
29540 ?        Sl     0:00 docker-containerd-shim 0c425984d9c544683de0644a77849807a9ee31db99043e3e2bace9d2e9cfdb63 /var/run/docker/libcontainerd/0c425984d9c544683de0644a77849807a9ee31db99043e3e2bace9d2e9cfdb63 docker-runc
29653 ?        Sl     0:00 docker-containerd-shim b1805c289749d432a0680aa7f082703175b647005d240d594124a64e69f5de28 /var/run/docker/libcontainerd/b1805c289749d432a0680aa7f082703175b647005d240d594124a64e69f5de28 docker-runc
29675 ?        Sl     0:36 docker-containerd-shim 6a9751b28d88c61d77859b296a8bde21c6c0c8379089ae7886b7332805bb8463 /var/run/docker/libcontainerd/6a9751b28d88c61d77859b296a8bde21c6c0c8379089ae7886b7332805bb8463 docker-runc
29831 ?        Sl     0:00 docker-containerd-shim 09796b77ef046f29439ce6cab66797314b27e9f77137017773f3b90637107433 /var/run/docker/libcontainerd/09796b77ef046f29439ce6cab66797314b27e9f77137017773f3b90637107433 docker-runc
30040 ?        Sl     0:20 docker-containerd-shim a2e26ba3d11f876b38e88cc6501fae51e7c66c7c2d40982eec72f23301f82772 /var/run/docker/libcontainerd/a2e26ba3d11f876b38e88cc6501fae51e7c66c7c2d40982eec72f23301f82772 docker-runc
30156 ?        Sl     0:00 docker-containerd-shim 35d157883a8c586e5086e940d1a5f2220e2731ca19dd7655c9ee3150321bac66 /var/run/docker/libcontainerd/35d157883a8c586e5086e940d1a5f2220e2731ca19dd7655c9ee3150321bac66 docker-runc
30326 ?        Sl     0:00 docker-containerd-shim 5af072f8c0b1af434139104ad884706079e2c46bf951200eaf9531614e2dc92a /var/run/docker/libcontainerd/5af072f8c0b1af434139104ad884706079e2c46bf951200eaf9531614e2dc92a docker-runc
30500 ?        Sl     0:00 docker-containerd-shim ba71715ba985511a617a7377b3b0d66f0b75af8323c17544c54f75da1a267a1f /var/run/docker/libcontainerd/ba71715ba985511a617a7377b3b0d66f0b75af8323c17544c54f75da1a267a1f docker-runc
30619 ?        Sl     0:08 docker-containerd-shim f42fdd0d4d971442969637f9e1db4c1e45270d86f950e614d8721d767872930a /var/run/docker/libcontainerd/f42fdd0d4d971442969637f9e1db4c1e45270d86f950e614d8721d767872930a docker-runc
30772 ?        Sl     0:00 docker-containerd-shim 8a745ab948d51e41b80992e2246058082f274d30d9f68f46dd3fef2e441afc01 /var/run/docker/libcontainerd/8a745ab948d51e41b80992e2246058082f274d30d9f68f46dd3fef2e441afc01 docker-runc
30916 ?        Sl     0:00 docker-containerd-shim 238f635c6adac1786ee46a99f0c20f36544cc5ebd644fc0c0908d38e9177eb1e /var/run/docker/libcontainerd/238f635c6adac1786ee46a99f0c20f36544cc5ebd644fc0c0908d38e9177eb1e docker-runc
31077 ?        Sl     0:00 docker-containerd-shim 9c208554dcb64c6568f026455a33d64830995c0411c6876fbea66355bab2cb5f /var/run/docker/libcontainerd/9c208554dcb64c6568f026455a33d64830995c0411c6876fbea66355bab2cb5f docker-runc
31252 ?        Sl     0:00 docker-containerd-shim afc0a4c93a27d9451875f8d917b24c64f59ba3b1992ff52f9ac3f93623440a54 /var/run/docker/libcontainerd/afc0a4c93a27d9451875f8d917b24c64f59ba3b1992ff52f9ac3f93623440a54 docker-runc
31515 ?        Sl     0:00 docker-containerd-shim b84b9b1d32bb9001359812a4dbbdf139c64c9eb9cf29475c73b2b498d990826f /var/run/docker/libcontainerd/b84b9b1d32bb9001359812a4dbbdf139c64c9eb9cf29475c73b2b498d990826f docker-runc
31839 ?        Sl     0:00 docker-containerd-shim 5b328bfc29a6a3033c1c5aa39fa38006538307aca3056f17d6421e5855bc496f /var/run/docker/libcontainerd/5b328bfc29a6a3033c1c5aa39fa38006538307aca3056f17d6421e5855bc496f docker-runc
32036 ?        Sl     0:00 docker-containerd-shim 5994ea24313b7e685321bd5bc03c0646c266969fa02f8061c0b4f1d94287f017 /var/run/docker/libcontainerd/5994ea24313b7e685321bd5bc03c0646c266969fa02f8061c0b4f1d94287f017 docker-runc
32137 ?        Sl     0:00 docker-containerd-shim aa4d9711bce7f85e04b94c8f733d0e29fb08763031fa81068acf9b5ee1bf3061 /var/run/docker/libcontainerd/aa4d9711bce7f85e04b94c8f733d0e29fb08763031fa81068acf9b5ee1bf3061 docker-runc

Ok, donc docker-containerd-shim voit ce point de montage et le maintient donc occupé. Je ne sais pas ce qu'est docker-containerd-shim et pourquoi le point de montage fuit là-bas. Qui sait.

@crosbymichael, vous le savez peut-être.

cc @mrunalp

Merci pour le ping. Je regarderai.

@ceecko pouvez-vous vérifier quel est l'espace de noms de montage de ces threads/processus docker-containerd-shim. Je soupçonne que ceux-ci ne partagent pas l'espace de noms de montage avec le démon docker et cela devrait probablement le faire.

@rhvgoyal Ils partagent le même espace de noms

docker

# ll /proc/16441/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  4 23:05 /proc/16441/ns/mnt -> mnt:[4026534781]

J'ai vérifié trois processus docker-containerd-shim

# ll /proc/23774/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  8 07:49 /proc/23774/ns/mnt -> mnt:[4026534781]
# ll /proc/27296/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  8 07:49 /proc/27296/ns/mnt -> mnt:[4026534781]
# ll /proc/31485/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  8 07:49 /proc/31485/ns/mnt -> mnt:[4026534781]

Nous n'avons pas de conteneurs morts qui ne pourraient pas être retirés maintenant.
Le fait est que deux fois par semaine, nous arrêtons et supprimons régulièrement tous les conteneurs et en commençons de nouveaux avec la même configuration. Avant ce "redémarrage", certains conteneurs finissent par être morts et ne peuvent pas être supprimés. Après le « redémarrage » régulier, la plupart des conteneurs sont morts, mais lorsque tous les anciens conteneurs sont arrêtés, tous les conteneurs morts peuvent être soudainement supprimés.

J'ai le même problème, mais j'obtiens également des erreurs supplémentaires lorsque j'essaie de recréer un conteneur avec docker-compose up -d :

Nov 10 13:25:21 omega dockerd[27830]: time="2016-11-10T13:25:21.418142082-06:00" level=info msg="Container b7fbb78311cdfb393bc2d3d9b7a6f0742d80dc5b672909408809bf6f7af55434 failed to exit within 10 seconds of signal 15 - using
Nov 10 13:25:21 omega dockerd[27830]: time="2016-11-10T13:25:21.530704247-06:00" level=warning msg="libcontainerd: container b7fbb78311cdfb393bc2d3d9b7a6f0742d80dc5b672909408809bf6f7af55434 restart canceled"
Nov 10 13:25:21 omega dockerd[27830]: time="2016-11-10T13:25:21.536115733-06:00" level=error msg="Error closing logger: invalid argument"
Nov 10 13:25:42 omega dockerd[27830]: time="2016-11-10T13:25:42.329001072-06:00" level=error msg="devmapper: Error unmounting device 0795abc37cc58b775ce4fb142271f5de5fa771477310321d1283f37ad6b20df9: Device is Busy"
Nov 10 13:25:42 omega dockerd[27830]: time="2016-11-10T13:25:42.329149437-06:00" level=error msg="Error unmounting container b7fbb78311cdfb393bc2d3d9b7a6f0742d80dc5b672909408809bf6f7af55434: Device is Busy"
Nov 10 13:25:42 omega dockerd[27830]: time="2016-11-10T13:25:42.544584079-06:00" level=error msg="Handler for GET /v1.24/containers/xbpf3invpull/logs returned error: No such container: xbpf3invpull"

En particulier, l'erreur Error closing logger: invalid argument , ainsi que l'erreur failed to exit within 10 seconds , dont je suis sûr qu'elle ne devrait pas se produire puisque j'utilise dumb-init pour démarrer mes conteneurs.

Ces erreurs sont-elles liées à ce problème ?

Je travaille actuellement sur un correctif pour cela. J'ai un PR ouvert dans containerd pour vous aider.

Il est difficile de trouver un moyen reproductible de tester cela. Une fois le correctif terminé, l'un de vous serait-il intéressé à tester ce correctif ?

Ouais absolument. Je vais essayer de créer une machine virtuelle dans laquelle je peux reproduire ce problème et essayer le correctif là-bas ; si cela ne fonctionne pas, je le testerai sur le serveur sur lequel j'ai des problèmes.

Je viens de créer une VM et j'ai pu (assez facilement !) reproduire le problème.

Voici ce que j'ai fait avec Virtualbox :

1. Installez une machine virtuelle Arch Linux simple (en utilisant le processus d'installation normal)
2. Installez docker, docker-compose et un autre démon sur lequel je peux exécuter plusieurs processus (dans ce cas, j'ai choisi nginx), puis systemctl enable docker et redémarrez le système
3. Configurer nginx pour qu'il s'exécute avec 500 processus de travail
4. Créez un fichier docker-compose avec 3 conteneurs de longue durée (j'ai choisi postgres, balise 9.2)
5. docker-compose up -d
6. systemctl start nginx
7. Modifiez les versions de quelques conteneurs à l'intérieur du fichier docker-compose pour utiliser la balise d'image 9.3
8. docker-compose pull
9. docker-compose up -d (il essaie de recréer les conteneurs, puis me donne l'erreur "Le périphérique est occupé" pour les deux conteneurs.

L'arrêt de nginx me permet de supprimer les conteneurs.

docker-compose.yml partir de maintenant (j'ai imité la configuration du docker de mon système défaillant):

Je peux fournir un accès à la VM sur demande, il suffit de me donner un e-mail pour envoyer le login.

@mlaventure Ce numéro peut-il être rouvert ? Pour le moment, nous ne savons pas si ce problème a été résolu ou non.

@SEAPUNK, nous mettrons à jour containerd avec ce correctif proposé. Si vous avez l'occasion de tester, je peux vous fournir des binaires à essayer.

Bien sûr, j'ai ma VM en veille.

Une idée de quand les binaires seront prêts ?

Les versions candidates https://github.com/docker/docker/releases

D'accord, je vais l'essayer ; Merci!

moi à tous,
Je pense que j'ai le même problème qui est signalé ici

[asantos<strong i="7">@fosters</strong> atp]$ docker-compose -f docker-compose-tst-u.yml rm api
Going to remove atp_api_1
Are you sure? [yN] y
Removing atp_api_1 ... error

ERROR: for atp_api_1  Driver devicemapper failed to remove root filesystem 63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472fbe8490656ed85f3f: Device is Busy



dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:15 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:15.943631263Z" level=error msg="Error removing mounted layer 63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472fbe8490656ed85f3f: Device is Busy"
dez 02 11:26:15 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:15.943863042Z" level=error msg="Handler for DELETE /v1.22/containers/63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472fbe8490656ed85f3f returned error: Driver devicemapper failed to remove root filesystem 63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472
dez 02 11:26:17 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:17.299066706Z" level=error msg="Handler for GET /containers/7ea053faaf5afac4af476a70d2a9611a6b882d6a135bcea7c86579a6ae657884/json returned error: No such container: 7ea053faaf5afac4af476a70d2a9611a6b882d6a135bcea7c86579a6ae657884"
dez 02 11:26:17 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:17.299608100Z" level=error msg="Handler for GET /containers/c3b1a805ed5d19a5f965d0ac979f05cbb59f362336041daea90a2fa4a1845d7d/json returned error: No such container: c3b1a805ed5d19a5f965d0ac979f05cbb59f362336041daea90a2fa4a1845d7d"


[asantos<strong i="8">@fosters</strong> atp]$ docker info
Containers: 4
 Running: 3
 Paused: 0
 Stopped: 1
Images: 110
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-253:1-1315304-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/fosters/docker-data
 Metadata file: /dev/fosters/docker-metadata
 Data Space Used: 10.71 GB
 Data Space Total: 20.72 GB
 Data Space Available: 10.02 GB
 Metadata Space Used: 16.73 MB
 Metadata Space Total: 2.303 GB
 Metadata Space Available: 2.286 GB
 Thin Pool Minimum Free Space: 2.072 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.131 (2016-07-15)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay null bridge host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.8-300.fc25.x86_64
Operating System: Fedora 25 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.672 GiB
Name: fosters.vi.pt
ID: EBFN:W46P:BMFR:OSJ5:UPY2:7KAT:5NMT:KAOF:XQI3:ITEM:XQNL:46P7
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: xxxxxxx
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

J'ai fini par avoir besoin de construire manuellement le binaire via PKGBUILD, car c'est plus simple et avec des ajustements, je peux forcer le PKGBUILD à utiliser un commit containerd spécifique (que j'ai défini sur docker/containerd@03e5862ec0d8d3b3f750e19fca3ee367e13c090e):

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/docker #n19

Je devrais avoir les résultats du correctif bientôt.

Je fais peut-être quelque chose de mal, mais je ne peux pas du tout démarrer les conteneurs maintenant :

Oh, je suppose que je dois mettre à jour runc... brb reconstruire

Oui, le correctif ne semble pas fonctionner :

docker info

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 8
Server Version: 1.13.0-rc2
Storage Driver: devicemapper
 Pool Name: docker-8:1-1835956-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: 745.6 MB
 Data Space Total: 107.4 GB
 Data Space Available: 27.75 GB
 Metadata Space Used: 2.744 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.145 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.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 51371867a01c467f08af739783b8beafc154c4d7
init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.8.11-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.864 GiB
Name: docker-vm
ID: KOVC:UCU5:5J77:P7I6:XXBX:33ST:H3UZ:GA7G:O7IF:P4RZ:VSSW:YBMJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

docker version

[root@docker-vm ~]# docker version
Client:
 Version:      1.13.0-rc2
 API version:  1.25
 Go version:   go1.7.4
 Git commit:   1f9b3ef
 Built:        Fri Dec  2 12:37:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:             1.13.0-rc2
 API version:         1.25
 Minimum API version: 1.12
 Go version:          go1.7.4
 Git commit:          1f9b3ef
 Built:               Fri Dec  2 12:37:59 2016
 OS/Arch:             linux/amd64
 Experimental:        false

À moins que vous ne puissiez reproduire cela dans votre propre machine virtuelle, je suis prêt à fournir un accès à ma machine virtuelle où je reproduis ce problème et à créer le package Docker personnalisé pour.

Je vois cela dans docker 1.12.3 sur CentOs 7

dc2-elk-02:/root/staging/ls-helper$ docker --version
Docker version 1.12.3, build 6b644ec
dc2-elk-02:/root/staging/ls-helper$ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64 #1 SMP lundi 24 octobre 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
dc2-elk-02:/root/staging/ls-helper$ docker rm ls-helper
Réponse d'erreur du démon : le mappeur de périphérique du pilote n'a pas réussi à supprimer le système de fichiers racine e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830 : le périphérique est occupé

Je n'utilise pas docker compose.

Je pense que je rencontre peut-être cette erreur aussi.

Je vois beaucoup de ces erreurs lorsque nous exécutons des tests d'acceptation pour Flocker :

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# journalctl  --boot --dmesg
...
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: dev_remove: 41 callbacks suppressed
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:35:00 acceptance-test-richardw-axpeyhrci22pi-1 kernel: XFS (dm-1): Unmounting Filesystem

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# journalctl --boot --unit docker
...
-- Logs begin at Tue 2016-12-13 17:30:53 UTC, end at Tue 2016-12-13 18:01:09 UTC. --
Dec 13 17:31:12 acceptance-test-richardw-axpeyhrci22pi-1 systemd[1]: Starting Docker Application Container Engine...
Dec 13 17:31:14 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:14.676133774Z" level=info msg="libcontainerd: new containerd process, pid: 1034"
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.209852977Z" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use `--storage-opt dm.thinpooldev` or use `man docker`
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.241124769Z" level=warning msg="devmapper: Base device already exists and has filesystem xfs on it. User specified filesystem  will be ignored."
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.259633105Z" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.423748590Z" level=info msg="Graph migration to content-addressability took 0.00 seconds"
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.443108711Z" level=info msg="Loading containers: start."
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.507397974Z" level=info msg="Firewalld running: true"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.025244392Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.195947610Z" level=info msg="Loading containers: done."
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.196550209Z" level=info msg="Daemon has completed initialization"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.196575340Z" level=info msg="Docker daemon" commit=1564f02 graphdriver=devicemapper version=1.12.4
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 systemd[1]: Started Docker Application Container Engine.
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.231752452Z" level=info msg="API listen on [::]:2376"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.231875125Z" level=info msg="API listen on /var/run/docker.sock"
Dec 13 17:32:41 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:32:41.631480676Z" level=error msg="devmapper: Error unmounting device 2a1e449a617f575520ef95c99fb8feab06986b7b86d81e7236a49e1a1cf192bb: Device is Busy"
Dec 13 17:32:41 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:32:41.632903143Z" level=error msg="Error unmounting container 117647e8bdd4e401d8d983c80872b84385d202015265663fae39754379ece719: Device is Busy"
Dec 13 17:33:20 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:33:20.300663432Z" level=error msg="devmapper: Error unmounting device 52e079667cf40f83b5be6d9375261500a626885581f41fc99873af58bc75939e: Device is Busy"
Dec 13 17:33:20 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:33:20.301660779Z" level=error msg="Error unmounting container 2aeabbd72f90da6d4fb1c797068f5c49c8e4da2182daba331dfe3e3da29c5053: Device is Busy"
Dec 13 17:34:50 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:34:50.461588888Z" level=error msg="devmapper: Error unmounting device 8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62: Device is Busy"
Dec 13 17:34:50 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:34:50.462602087Z" level=error msg="Error unmounting container e0c45f71e2992831a10bc68562bcc266beba6ef07546d950f3cfb06c39873505: Device is Busy"

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 4
Server Version: 1.12.4
Storage Driver: devicemapper
 Pool Name: docker-8:1-1072929-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: 525.5 MB
 Data Space Total: 107.4 GB
 Data Space Available: 8.327 GB
 Metadata Space Used: 1.384 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 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-RHEL7 (2016-09-28)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: flocker local
 Network: host bridge overlay null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-514.2.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.305 GiB
Name: acceptance-test-richardw-axpeyhrci22pi-1
ID: 4OHX:ODXJ:R2MH:ZMRK:52B6:J4TH:PMDR:OQ5D:YUQB:5RE3:YDAQ:V5JP
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

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# cat /usr/lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

@rhvgoyal @rhatdan @vbatts
Exécution de problèmes « Périphérique occupé » lors de la suppression/suppression de conteneurs arrêtés/morts sur RHEL7.1 exécutant dockerd 1.12.4 avec suppression et suppression différées enabled=true sans aucun MountFlags dans les fichiers unitaires systemd docker.service.
Voir également des messages du noyau comme :
"kernel: device-mapper: thin: La suppression du périphérique thin 120 a échoué." (120 étant l'identifiant de périphérique du périphérique Thinpool du conteneur en cours de suppression)

Dans tous les cas, le point de montage du périphérique thinpool devicemapper pour le conteneur en cours de suppression a été divulgué dans l'espace de noms de montage d'un autre pid sur l'hôte qui est démarré avec MountFlag=private/slave.

• ntpd.service est démarré avec PrivateTmp=true dans RHEL
• Le service systemd-udevd est démarré avec MountFlags=slave dans RHEL
  Sur les hôtes où les suppressions de conteneurs échouent, l'un ou l'autre de ces processus a été redémarré après l'heure de début du conteneur correspondant.

Il semble donc qu'il soit très facile de divulguer des points de montage dans l'espace de noms de montage hôte, car les processus système ci-dessus ne partagent pas certains espaces de noms de montage, par défaut, qui ne peuvent pas être modifiés/contrôlés individuellement.
L'exécution de dockerd avec mountflags=slave est-elle la seule solution ici ? Pouvez-vous également m'aider à comprendre pourquoi le mountflags=slave (et par défaut partagé) a été supprimé il y a quelque temps du fichier d'unité docker systemd.
Dans quels scénarios, l'exécution de dockerd avec la propagation du point de montage esclave casse d'autres choses ?
Merci.

Il existe des différences entre le noyau RHEL et le noyau en amont auxquelles nous essayons de remédier, ce qui nous oblige à exécuter le dockerd dans son propre espace de noms de montage, dans Fedora le noyau fonctionne différemment ce qui nous permet d'exécuter le dockerd dans l'espace de noms de l'hôte.

@rhvgoyal peut vous donner les détails sanglants.

@ravilr , sur les noyaux rhel/centos, désactiver la suppression différée. Le noyau n'a pas de correctifs pour le prendre en charge.

Exécutez également docker avec MountFlags=slave

Vous pouvez continuer à utiliser la suppression différée sur les noyaux rhel/centos et cela devrait fonctionner.

BTW, si vous utilisez docker-storage-setup pour configurer le stockage, il déterminera automatiquement si le noyau sous-jacent prend en charge la suppression différée ou non et définira/désactivera cette option en conséquence.

@rhvgoyal connaissez-vous un moyen de libérer de l'espace après l'échec de la suppression du système de fichiers racine du conteneur ?

@rhvgoyal Merci pour les suggestions. Je vais essayer comme vous l'avez suggéré et faire rapport ici, si nous continuons à voir des problèmes liés à la suppression des conteneurs.

Cogner; avez-vous besoin de plus d'informations pour aider à résoudre ce problème ?

J'ai frappé moi-même en exécutant 1.12.5 sur Centos 7.

L'activation de moutflags=slave ainsi que l'activation de la suppression et de la suppression différées ont résolu ce problème pour moi. Maintenant, je rencontre ce bogue de condition de concurrence : https://github.com/docker/docker/issues/23418

C'est environ 100 fois mieux que d'avoir à retirer de force les conteneurs bloqués, mais ce n'est toujours pas génial.

Je peux reproduire sur un CentOS 7 sur xfs.

Même problème ici, Docker 1.13.0 - CentOS7 :

docker-compose down
Removing container_container_1 ... error

ERROR: for container_container_1  Driver devicemapper failed to remove root filesystem 4d2d6c59f8435436e4144cc4e8675a0828658014cf53804f786ef2b175b4b324: Device is Busy

Une résolution en vue sur celui-ci ? Je vois toujours le problème et mes tentatives pour trouver le processus maintenant l'appareil ouvert ont échoué. Il ne semble pas y avoir de processus maintenant le périphérique occupé ouvert.

Merci.

(Mise à jour de mon commentaire : ce n'était pas clair lors de la première lecture du fil, mais il semble que l'activation de la suppression différée et la définition de MountFlags=slave puissent le corriger. Je mettrai également à jour Docker vers 1.13.)

quelqu'un qui souhaite résoudre ce problème pourrait voir le commentaire de @ravilr ci-dessus, les détails ci-dessous :

Dans tous les cas, le point de montage du périphérique thinpool devicemapper pour le conteneur en cours de suppression a été divulgué dans l'espace de noms de montage d'un autre pid sur l'hôte qui est démarré avec MountFlag=private/slave.

ntpd.service est démarré avec PrivateTmp=true dans RHEL
Le service systemd-udevd est démarré avec MountFlags=slave dans RHEL
Sur les hôtes où les suppressions de conteneurs échouent, l'un ou l'autre de ces processus a été redémarré après l'heure de début du conteneur correspondant.

either of these processes were restarted after the corresponding container start time. est le point clé, les fichiers dans certains répertoires comme "tmp" sont utilisés par un autre espace de noms pas seulement le conteneur docker, donc docker ne peut pas les tuer sans forcer.
vous pouvez résoudre ce problème en arrêtant les processus redémarrés ou en définissant leur paramètre systemd PrivateTmp=true sur false et les redémarrer.

référence : https://www.freedesktop.org/software/systemd/man/systemd.exec.html

@KevinTHU Peut-être que je comprends mal vos commentaires.

Mais dans mon cas (ubuntu 14.04), tout ce que j'ai à faire pour résoudre ce problème, c'est de redémarrer le service docker lui-même
( service docker restart ). aucun "ntpd.service" ou "systemd-udevd service" n'est impliqué.

Est-ce sensé ?

@quexer bien sûr, le redémarrage de docker peut résoudre ce problème, mais, tout le conteneur sera également redémarré, c'est trop coûteux pour un environnement de production

@KevinTHU le redémarrage du service docker Ne pas affecter tout conteneur en cours d' exécution. Vous pouvez l'essayer vous-même.

@quexer Cela dépend de votre configuration. Mais je soupçonne que si vous laissez les conteneurs fonctionner avec le mode --live-restore , cela peut ne pas résoudre le problème.
Par défaut, Docker arrêtera tous les conteneurs à la sortie, puis s'il y a quelque chose lors de la sauvegarde, il les tuera également.

@cpuguy83 @KevinTHU Désolé, c'est de ma faute. Vous avez raison, redémarrer docker entraînera le redémarrage de tous les conteneurs.

Je reçois maintenant cela régulièrement avec l'une de mes machines virtuelles, à l'improviste. Fait intéressant, l'un d'eux est devenu effaçable après plus de 8 heures d'absence. Voici mes infos :

rlpowell@vrici> sudo docker info
Containers: 15
 Running: 3
 Paused: 0
 Stopped: 12
Images: 155
Server Version: 1.12.6
Storage Driver: devicemapper
 Pool Name: docker-253:0-2621441-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: 24.5 GB
 Data Space Total: 107.4 GB
 Data Space Available: 24.28 GB
 Metadata Space Used: 29.57 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.118 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: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: host bridge null overlay
 Authorization: rhel-push-plugin
Swarm: inactive
Runtimes: oci runc
Default Runtime: oci
Security Options: seccomp selinux
Kernel Version: 4.9.0-0.rc1.git4.1.fc26.x86_64
Operating System: Fedora 26 (Server Edition)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 4
Total Memory: 8.346 GiB
Name: vrici.digitalkingdom.org
ID: JIIS:TCH7:ZYXV:M2KK:EXQH:GZPY:OAPY:2DJF:SE7A:UZBO:A3PX:NUWF
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://registry.access.redhat.com/v1/
Insecure Registries:
 127.0.0.0/8
Registries: registry.access.redhat.com (secure), docker.io (secure)

Et c'est à nouveau cassé.

Je ne sais pas si cela est pertinent, mais /var/log/messages a :

14 février 16:58:49 vrici kernel: dev_remove: 40 rappels supprimés
14 février 16:58:54 vrici kernel: dev_remove: 40 rappels supprimés
14 février 16:58:59 vrici kernel: dev_remove: 40 rappels supprimés

L'erreur en ce moment est :

Réponse d'erreur du démon : le gestionnaire de périphériques n'a pas réussi à supprimer le système de fichiers racine b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e : n'a pas réussi à supprimer le périphérique dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08b79fde Bus

L'appareil est occupé quelque part. Pouvez-vous essayer de suivre le script après l'échec et voir où l'appareil peut être occupé.

https://github.com/rhvgoyal/misc/blob/master/find-busy-mnt.sh

./trouver-occupé-mnt.sh

./find-busy-mnt.sh dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde681

rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
Aucun pid trouvé
rlpowell@vrici> sudo docker rm freq_build
Réponse d'erreur du démon : Le mappeur de périphérique du pilote n'a pas réussi à supprimer le système de fichiers racine b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10 : n'a pas réussi à supprimer le périphérique 5f1095868bbfe85afccf392f6f4fbb8ed4vicebcfac88a63a8044bb

Oh, on dirait que c'était le mauvais hachage.

rlpowell@vrici> mount | grep b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh 5f1095868bbfe85afccf392f6f4fbb8ed4bcfac88a5a8044bb122463b765956a
PID     NAME            MNTNS
12244   php-fpm         mnt:[4026532285]
12553   php-fpm         mnt:[4026532285]
12556   php-fpm         mnt:[4026532285]
12557   php-fpm         mnt:[4026532285]
12558   php-fpm         mnt:[4026532285]
rlpowell@vrici> pg php-fpm
rlpowell 25371 10518  0 00:43 pts/9    00:00:00  |           \_ grep --color=auto php-fpm
root     12244     1  0 00:08 ?        00:00:00 php-fpm: master process (/etc/php-fpm.conf)
apache   12553 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
apache   12556 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
apache   12557 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
apache   12558 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
rlpowell@vrici> sudo service php-fpm stop
Redirecting to /bin/systemctl stop  php-fpm.service
rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh 5f1095868bbfe85afccf392f6f4fbb8ed4bcfac88a5a8044bb122463b765956a
No pids found
rlpowell@vrici> sudo docker rm freq_build
freq_build

C'est... extrêmement bizarre. Je n'ai aucune idée de la raison pour laquelle un processus php-fpm totalement indépendant serait perçu par le noyau comme maintenant ces montages ouverts.

@rlpowell Oui, c'est tout le problème derrière ce problème. Quelque chose empêche l'espacement des noms de montage de fonctionner correctement.

J'ai trouvé ce qui semble être une solution de contournement ici : http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Cela signifie essentiellement ajouter la ligne suivante à votre fichier systemd docker.service :
MountFlags=privé

Cela semble fonctionner, du moins pour le petit échantillon d'exécutions de docker que j'ai effectuées depuis son déploiement. Ce serait bien si quelqu'un qui comprend parfaitement docker pouvait expliquer les conséquences de ce drapeau, je soupçonne que les systèmes de fichiers montés après le démarrage de docker peuvent ne pas devenir disponibles pour les conteneurs, mais honnêtement, je ne sais pas. Notre configuration est destinée à être utilisée sur un serveur de build et là, les choses semblent bien fonctionner.

Problème assez majeur, cela rend effectivement docker inutilisable sur Centos 7/RHEL - (et ouvert depuis 4 mois ?)
Une heure d'arrivée prévue ?

Le dernier RHEL/centos doit être livré avec MountFlags=slave dans le fichier docker.service.

@rhvgoyal ce n'est pas le cas : https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm

C'est sur la branche master, mais les branches 1.13.x et 17.03.x ne l'ont pas non plus.

Pour autant que je sache, c'est que ce drapeau était dans une unité de service précédente mais a été supprimé. Mais je n'ai pas trouvé pourquoi. Peut-être que ces drapeaux résolvent le problème actuel mais créent d'autres problèmes.

@rlpowell @SEAPUNK il semble que ce ne soit pas le cas dans mon installation ubuntu :

$ docker rm test
Error response from daemon: Driver devicemapper failed to remove root filesystem f23064c71f22215f8cc7c7192488ab1bbb24693b36e07018b32d58292ee6ce47: Device is Busy
$ sudo ./find-busy-mnts.sh f23064c71f22215f8cc7c7192488ab1bbb24693b36e07018b32d58292ee6ce47
No pids found

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

$ docker version
Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ docker info
Containers: 17
 Running: 14
 Paused: 0
 Stopped: 3
Images: 148
Server Version: 1.13.1
Storage Driver: devicemapper
 Pool Name: ubuntu--vg-thinpool
 Pool Blocksize: 524.3 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: 
 Metadata file: 
 Data Space Used: 29.3 GB
 Data Space Total: 386.5 GB
 Data Space Available: 357.2 GB
 Metadata Space Used: 16.97 MB
 Metadata Space Total: 4.295 GB
 Metadata Space Available: 4.278 GB
 Thin Pool Minimum Free Space: 38.65 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.110 (2015-10-30)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-62-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 15.56 GiB
Name: martin
ID: W4KC:COLM:3G33:I54E:PNUD:A5XX:TEBZ:VG43:BR62:JWCU:B44Y:DQWJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

J'ai écrit un article expliquant pourquoi RHEL7 ne peut pas prendre en charge --live-restore jusqu'à RHEL7.4 et pourquoi docker doit être exécuté dans un espace de noms de montage différent de celui de l'hôte.

https://access.redhat.com/articles/2938171

+1 Je voudrais exécuter avec un espace de noms de montage différent et rendre tous les montages docker privés.
Il y a cependant des éléments délicats.

Si le docker en amont n'a pas d'indicateur approprié pour s'exécuter dans le MountFlags=slave il s'agit d'un bogue et cela déclenchera facilement des problèmes de fuite d'espaces de noms de montage entre les conteneurs et l'hôte et peut entraîner des problèmes de suppression des images de conteneur.

FWIW, le MountFlags=slave été supprimé dans https://github.com/docker/docker/pull/22806 , après examen par les responsables de Red Hat, mais il semble que cela cause des problèmes, alors je me demande si cela devrait être annulé jusqu'à RHEL7.4 ?

Oui, nous l'avions supprimé et plus tard, cela a causé des problèmes. Je pensais que tu l'avais déjà fait. Je ne me souviens plus de quel fil il s'agissait.

@thaJeztah Oui, nous nous sommes trompés et avons trouvé des problèmes supplémentaires.

Et ces problèmes étaient principalement spécifiques aux noyaux plus anciens. Les noyaux plus récents fonctionnent très bien.

Permettez-moi d'ouvrir un PR pour discuter des options

PR ouvert ici; https://github.com/docker/docker/pull/31490

même problème (docker 1.10.3) CentOS Linux version 7.2.1511
dmesg：
[1732917.246900] device-mapper : ioctl : impossible de supprimer le docker de périphérique ouvert-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78
messages:
3 avril 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346374677+08:00" level=error msg="Erreur lors de la suppression de la couche montée b0b1e839f366086fd7cff564feee385a3aed71a56db90724c13f41652a17a "
3 avril 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346597095+08:00" level=error msg="Handler for DELETE /v1.22/containers /b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2d a renvoyé une erreur : le mappeur de périphérique du pilote n'a pas réussi à supprimer le système de fichiers racine b0b1e839f366086fd7cff564feee385a3aed71a04165y"Périphérique :

monter:
trouver /proc/*/mounts | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
/ proc / 159779 / mounts: / dev / Mapper / docker-8: 3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / export / docker / carte des périphériques / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS rw, relatime, nouuid, attr2, inode64, logbsize = 64k, sunit = 128, largeur=128,pas de quota 0 0
/ proc / 159806 / mounts: / dev / Mapper / docker-8: 3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / export / docker / carte des périphériques / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS rw, relatime, nouuid, attr2, inode64, logbsize = 64k, sunit = 128, largeur=128,pas de quota 0 0
nouveau conteneur
docker inspecte 8777d36c94ec|grep Pid
"Pid": 159779,

//ma faute， je l'ai résolu 。

Qu'est-ce que l'ID « 8777d36c94ec » ? Il s'agit de l'ID du conteneur en cours de suppression ou d'un autre conteneur ?

L'appareil est donc occupé car il est toujours monté dans le conteneur. Ainsi, l'un ou l'autre des conteneurs supprimés ne s'est pas encore arrêté. Ou s'il s'agit d'un conteneur différent, il ne devrait pas être visible dans un autre conteneur.

Vous ne savez pas quel est le point de montage "/export/docker/devicemapper/mnt/...." et qui a créé cela ?

Sur mon système Mint, la mise à niveau de 17.03.1~ce-0~ubuntu-xenial vers 17.04.0~ce-0~ubuntu-xenial provoque ce problème très fréquemment.

Avant la mise à niveau, je ne l'avais jamais rencontré. Après la mise à niveau, c'était très fréquent. Le retour à la version 17.03.1 semble l'avoir résolu.

Juste comme note pour les autres lecteurs de ce fil, si vous exécutez cAdvisor de Google, vous verrez ce problème lorsque vous essayez de supprimer un conteneur. Vous devez d'abord arrêter cAdvisor, puis supprimer le conteneur, puis redémarrer cAdvisor.

@bmbroom Idem. Nous exécutons des serveurs de build basés sur Ubuntu qui désactivent les conteneurs toute la journée (généralement pilotés par docker-compose), et nous avons vu ce problème quelques fois par semaine. Les serveurs sont un mélange de fidèles et de xenials. Nous avons récemment commencé la mise à niveau vers 17.04.0~ce et voyons cela se produire plusieurs fois par jour maintenant.

Je ne sais pas si MountFlags=slave est applicable à Ubuntu, mais c'est ce que j'essaie ensuite.

@rhvgoyal
Désolé, c'est de ma faute.
d'autres encore montés dans mon container。

Je viens d'avoir le même problème sur :

• docker : Docker version 17.03.1-ce, build c6d412e
• système d'exploitation : Red Hat Enterprise Linux Server version 7.3 (Maipo)
• noyau : 3.10.0-514.6.1.el7.x86_64
• ntpd: 4.2.6p5

Faire systemctl restart ntpd résolu le problème instantanément.

@xeor
quel est votre MountFlags dans le fichier d'unité docker.service ?

Il n'y a pas de MountFlags dans mon fichier /usr/lib/systemd/system/docker.service , mais systemctl show docker affiche MountFlags=0 .

Idem pour ntpd.service . Qui ont également le PrivateTmp=true sous la strophe [Service] (si cela compte).

Exécutez avec MountFlags=slave pour le moment.

@rhvgoyal a vérifié mon fichier docker.service. Mais votre valeur est déjà définie :

grep MountFlags /etc/systemd/system/multi-user.target.wants/docker.service
MountFlags=slave

en utilisant le dernier redhat(3.10.0-514.16.1.el7)/docker(1.12.6-16.el7)

qu'en est-il de MountFlags=private ? Pourriez-vous expliquer la différence entre privé et esclave ?

Je vois actuellement ce problème sur RHEL/CentOS 7.3, noyau 3.10.0-514.16.1.el7.x86_64, avec Docker version 17.05.0-ce, build 89658be. Nous avons vu ce problème par intermittence au cours de la dernière année.

Nous n'avons pas non plus d'option MountFlags dans /etc/systemd/system/multi-user.target.wants/docker.service. Doit-on y ajouter "MountFlags=slave" ?

Je vois des commentaires disant que ce problème se produit dans Centos, RHEL et Ubuntu. Les autres systèmes d'exploitation sont-ils à l'abri de ce problème particulier, comme Debian, ContainerLinux ou SUSE ?

@earwax Tout ce qui a un noyau plus récent (>= 3.15) devrait généralement mieux fonctionner.
Mais il y a toujours des situations que vous pouvez créer où cette erreur se produit.
En outre, il existe plusieurs façons énumérées dans les commentaires ici pour l'atténuer.

Je vois ce problème sur SUSE... mais je n'ai pas trouvé de solution à ce problème... Je vois que cela se produit principalement sur le fournisseur : AZURE

nous trouvons également ce problème, lorsque nous avons mis à jour dockerd de 1.12.6 à 17.05. Tous les anciens conteneurs ne pouvaient pas être supprimés sans '-f', ces conteneurs avaient une caractéristique commune qu'ils n'étaient pas tous arrêtés lors de la mise à jour de dockerd, car nous avons la configuration '--live-restore'. Je pense qu'il y a un problème ici.

C'est toujours un problème dans 17.06, pour info, au moins avec CentOS 7.

@ MGD1981 ce bogue doit être corrigé, nous utilisons le même centos 7 et nous découvrons que non seulement les anciens conteneurs créés avant la mise à jour de docker ont un problème "l'appareil est occupé", mais aussi les nouveaux conteneurs créés, c'est vraiment critique , et nous le contournons en ajoutant "MountFlags=slave" à docker.service. Cependant, nous ne savons pas si ce paramètre apportera un autre problème.

Oui, en train d'essayer maintenant dans notre environnement d'assurance qualité. fera très attention
aux montures. Y a-t-il un risque potentiel que le FS d'un conteneur soit
"oublié" avec ce paramètre, au fil du temps, remplissant l'hôte de disques
de conteneurs morts?

Le lundi 3 juillet 2017, 22h38, KevinTHU [email protected] a écrit :

@MGD1981 https://github.com/mgd1981 ce bug doit être corrigé, nous sommes
en utilisant centos 7 de la même manière, et nous découvrons que non seulement les anciens conteneurs
créé avant la mise à jour de docker a un problème "l'appareil est occupé", mais aussi le
nouveaux conteneurs créés, c'est vraiment critique, et nous le contournons en
en ajoutant "MountFlags=slave" à docker.service. Cependant, nous ne savons pas si
ce paramètre apportera un autre problème.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/27381#issuecomment-312766596 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.

@MGD1981 oui, il semble y avoir des disques sur l'hôte qui ne sont plus utilisés. Voir #33025

@ceecko Cela ne devrait plus se produire à partir du 17.06, bien que si vous activez la suppression/suppression différée, il se peut qu'il ne soit pas nettoyé immédiatement.

@cpuguy83 sympa ! Nettoyera-t-il également les anciens disques laissés par les versions précédentes ?

@cpuguy83 est-il encore sorti 17.06 ? (on est déjà en juillet, donc 17.07 ?) on ne le trouve pas dans la page des versions de github.

@ravilr C'est parti. Les versions proviennent de github.com/docker/docker-ce.

@ceecko Je ne pense pas.

@cpuguy83 merci. les notes de version pour 17.06 ne semblent pas mentionner de correctifs pr concernant ce problème. quelle a été la solution pour résoudre ce problème ? Merci encore.

@ravilr ce PR https://github.com/moby/moby/pull/31012

J'exécute 17.06.0-ce sur CentOS 7 (avec stockage en pool léger) et cela se produit beaucoup ces derniers temps.

+ docker rm -f jenkins-build_rcc_testrun-1945
Error response from daemon: driver "devicemapper" failed to remove root filesystem for d626082dffb7c52fa8c012a2de3b113e431d1bdbc834084654051900e9482f23: failed to remove device 01c54a8701901f7fcb096e61b9028665df7f0596a0ad01d8ce0cd88215959d14: Device is Busy
Build step 'Execute shell' marked build as failure

Est-ce avec ou sans MountFlags=slave , @AaronDMarasco-VSI ? CentOS 7.3 ?

17.06 ne résout pas le problème fondamental, c'est juste mieux pour le gérer.
Je regarde s'il y a quelque chose que docker (ou un sous-composant comme containerd) fait qui aggrave le problème.

@esabol Non... privé ?

docker.service.d$ cat * | grep -v '^#'
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --exec-opt native.cgroupdriver=cgroupfs --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg_ex-docker--pool --storage-opt dm.use_deferred_removal=true

[Unit]
After=lvm2-lvmetad.socket lvm2-activation.service lvm2-lvmetad.service

[Service]
MountFlags=private

docker.service.d$ cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 

Eh bien, @AaronDMarasco-VSI, je conseillerais de changer cela en MountFlags=slave , ce qui a amélioré la situation pour nous, mais nous sommes toujours au 17.05 et je pense avoir vu quelque part que vous ne voulez pas utiliser MountFlags=slave avec dm.use_deferred_removal ? Peut-être que quelqu'un d'autre commentera et confirmera.

J'utilise docker 17.03 sur centos 7.3 et kernel 4.10. et j'ai vu cette erreur beaucoup. Vous trouverez ci-dessous quelques détails supplémentaires sur MountFlag.

# systemctl show docker | grep Private
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
# systemctl show docker | grep Mount
MountFlags=0

même problème ici avec Debian 8. cela casse notre CI, une solution possible ??

@ thg303 essayez d'arrêter votre dockerdeamon, si possible et essayez de nettoyer/supprimer le système de fichiers racine qui apparaît dans votre fichier journal (rm /var/lib/docker/..... ). Mais vous devriez prendre un instantané/une sauvegarde avant :-)

Même problème ici avec Fedora 25, noyau 4.11.12.

Containers: 5
 Running: 0
 Paused: 0
 Stopped: 5
Images: 16
Server Version: 17.06.0-ce
Storage Driver: devicemapper
 Pool Name: docker-253:2-5373989-pool
 Pool Blocksize: 65.54kB
 Base Device Size: 21.47GB
 Backing Filesystem: xfs
 Data file: /dev/loop1
 Metadata file: /dev/loop2
 Data Space Used: 59.33GB
 Data Space Total: 107.4GB
 Data Space Available: 48.05GB
 Metadata Space Used: 76.11MB
 Metadata Space Total: 2.147GB
 Metadata Space Available: 2.071GB
 Thin Pool Minimum Free Space: 10.74GB
 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
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.11.12-200.fc25.x86_64
Operating System: Fedora 25 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.703GiB
Name: wayland
ID: 3T2X:CMFA:53Y2:27FL:RBMD:FHMH:32QE:2DKL:L256:O2GJ:LT2X:N4DD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Http Proxy: http://127.0.0.1:8118/
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: devicemapper: usage of loopback devices is strongly discouraged for production use.
         Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.

J'ai ce problème à chaque fois que docker est mis à jour sur centos7. Je redémarre docker et puis tout fonctionne bien.

Idem pour moi sur Fedora 26 avec Docker 17.06.0-ce. Le redémarrage de docker n'a pas résolu le problème.

$ systemctl show docker | grep Private
PrivateTmp=no
PrivateDevices=no
PrivateNetwork=no
PrivateUsers=no
$ systemctl show docker | grep Mount
MountFlags=0
MountAPIVFS=no

Sérieusement à venir dans un an maintenant et ce bug est toujours là ?

@NeckBeardPrince S'il vous plaît, ne perdez pas notre temps avec des commentaires aussi inutiles.
Si vous souhaitez aider à le résoudre, tant mieux. Si vous souhaitez signaler plus de données sur le problème, c'est parfait.

En dehors de cela, il existe plusieurs façons de contourner ce problème qui ont été publiées ici.

Le fichier d'unité systemd n'est pas livré avec MountFlags=slave

Server Version: 17.06.1-ce
CentOS Linux release 7.3.1611 (Core)

[root<strong i="7">@dokken</strong> /]# systemctl show docker | grep Private
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
[root<strong i="8">@dokken</strong> /]# systemctl show docker | grep Mount
MountFlags=0

La dernière fois que j'ai eu ce problème, c'était ntpd qui tenait les montures.
Aujourd'hui, j'ai eu le même problème, et cette fois, c'était une instance mariadb cours d'exécution sur l'hôte qui était la raison.

• docker-engine-17.05.0.ce-1.el7.centos.x86_64
• mariadb-server-5.5.56-2.el7.x86_64

Exemple pour trouver le proc contenant les montures....

# container with the problem
docker rm efad7...
Error response from daemon: Driver devicemapper failed to remove root filesystem efad7...: remove /var/lib/docker/devicemapper/mnt/9bd66290ee...: device or resource busy

# Grep after parts of the mountpoint
grep docker /proc/*/mountinfo | grep 9bd66290ee
/proc/9736/mountinfo:776 427 253:24 / /var/lib/docker/devicemapper/mnt/9bd66290e...
/proc/9910/mountinfo:776 427 253:24 / /var/lib/docker/devicemapper/mnt/9bd66290e...

# Find who the pid's belongs to
ps aux | grep -E "9736|9910"
mysql     9736  0.0... /usr/bin/mysqld_safe --basedir=/usr
mysql     9910  9.8 ... /usr/libexec/mysqld --base...

# Do some extra research on one of the pids
grep docker /proc/9736/mountinfo | wc -l
70

grep docker /proc/9736/mountinfo | grep -o "/run/docker/netns/" | wc -l
17

grep docker /proc/9736/mountinfo | grep -o "/var/lib/docker/containers/" | wc -l
18

grep docker /proc/9736/mountinfo | grep -o "/var/lib/docker/devicemapper/mnt/" | wc -l
33

Après avoir redémarré mariadb, il a lâché les points de montage, cependant, il en a récupéré beaucoup au démarrage.

grep docker /proc/16367/mountinfo | wc -l
52

La plupart des échecs de suppression sont dus au fait que le point de montage (donc device ) est occupé dans d'autres espaces de noms de montage. Je pense que le PR proposé ci-dessous aidera à résoudre ce problème si le noyau est suffisamment nouveau.

https://github.com/moby/moby/pull/34573

Si vous utilisez un ancien noyau, nous avons écrit un appel de plug-in oci-umount pour réduire les problèmes de fuite de montage.

https://github.com/projectatomic/oci-umount

@rhvgoyal Avez-vous un plan sur quelle version de docker inclure ce PR ? Nous traitons toujours avec le driver "devicemapper" failed to remove root filesystem sur une base régulière.

CentOS Linux version 7.4.1708 (Core)
3.10.0-693.5.2.el7.x86_64
17.06.2-ce

IL RESSEMBLE QUE C'EST ENFIN FIXE

Nous utilisons Docker version 17.09.0-ce et rencontrons toujours le même problème.

Nous rencontrons occasionnellement ce problème sur Oracle Linux :, avec docker version 17.03.1-ce (à partir des dépôts d'Oracle)

Linux server 4.1.12-103.3.8.1.el7uek.x86_64 #2 SMP Fri Sep 15 17:23:08 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

Tout ce qui précède est corrigé par le TDA du projet, nous ne pouvons donc rien y changer pour le moment.

90% de nos autres environnements sont Centos 7.3/7.4, et nous n'avons pas vu le problème là-bas.

Je viens de réussir à résoudre une instance de ce problème avec Docker 17.05 sur arch Linux sur 4.11.9
par

1. docker rm -f [myContainer] (échec avec le driver "devicemapper" failed to remove root filesystem comme d'habitude)
2. ls /var/lib/docker/devicemapper/mnt/

Cela a finalement fait disparaître le conteneur (je ne sais pas pourquoi cependant).

@MonsieurWave aussi incroyable que cela

Le docker rm -f [container] signalera un échec mais finira par nettoyer le conteneur et le système de fichiers. La commande ls est un faux-fuyant, tout ce dont vous avez vraiment besoin est d'attendre quelques secondes. Mais mieux que cela, c'est d'utiliser MountFlags=slave . Et le mieux est de désactiver devicemapper et d'utiliser overlay2 à la place.

Et le mieux est de désactiver devicemapper et d'utiliser overlay2 à la place.

Nous utilisons Docker sur CentOS 7.x (actuellement à 7.4) depuis plus d'un an maintenant. Lorsque nous avons installé Docker pour la première fois, tout le monde a dit que vous deviez utiliser devicemapper avec direct-lvm pour les meilleures performances et stabilité. https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ indique toujours que vous devez utiliser devicemapper sur CentOS avec Docker EE. Heureusement, nous utilisons Docker CE, nous avons donc pu passer à overlay2. J'ai l'impression que les gens de Docker ont glissé dans le changement de la valeur par défaut de devicemapper à overlay2 sur CentOS dans v1.13.0/1 avec peu de fanfare ou de discussion. Existe-t-il des informations solides sur les performances/stabilité d'overlay2 par rapport à devicemapper (direct-lvm) sur CentOS 7 ? Ma recherche sur Google n'a pas trouvé grand chose...

Nous avons passé un très mauvais moment avec les noyaux CentOS 7.2 d'origine (leur frankenstein 3.10.x). Beaucoup d'accidents. Nous utilisions Kubernetes dans un environnement de développement, le taux de désabonnement de nos conteneurs était donc très élevé, mais même dans des installations relativement silencieuses, nous avons trouvé le combo CentOS + overlay d'origine très instable. L'exécution d'un noyau en amont 4.10+ avec overlay2 est bien meilleure. Je n'ai pas essayé une version plus récente de CentOS.

Vous devrez soit utiliser un système de fichiers sous-jacent qui est ext4 ou XFS formaté avec "-n ftype=1". Docker s'exécutera si vous avez un XFS mal formaté, mais les résultats seront imprévisibles.

Oui, je suis passé depuis longtemps à overlay2 et je recommande à tous ceux qui utilisent encore devicemapper qui peuvent utiliser overlay2 pour basculer , car même ce problème mis à part, j'ai lu que devicemapper est un très mauvais pilote de stockage pour docker en général.

Le redémarrage de ntpd a résolu le problème que j'avais... tellement déroutant. Existe-t-il une configuration daemon.json "recommandée" pour docker sur Centos7 ?

Certaines améliorations sont à venir.

Plus précisément, le problème avec ces autres services système semble être une condition de concurrence avec la configuration d'espaces de noms de montage (pour ces autres services système) et la tentative de docker de garder ses propres montages privés ... l'intention est que Docker empêche ses montages de fuir dans conteneurs, malheureusement, cela provoque des fuites ailleurs et finit par contenir des références privées à ces points de montage, ce qui signifie qu'ils ne peuvent pas être démontés dans ces espaces de noms, sauf manuellement ou lorsque le processus redémarre.

De plus, il y a eu quelques changements récents pour gérer les conditions de concurrence avec l'utilisation de la propagation de montage MS_PRIVATE dans runc et docker.
La prochaine version sera-t-elle parfaite ? Probablement pas... mais je m'attends à ce que cela s'améliore.

J'ai exactement la même chose que @ceecko avec docker 12.1.1 , aucune chance de mettre à jour maintenant. Est-ce que c'est réparé plus tard quelque part ? La solution rapide consiste à tuer les processus et à redémarrer le service Docker, mais ..

Ces versions résolvent complètement le problème pour moi, y compris --live-restore

CentOS 7.4.1708 (3.10.0-693.5.2.el7.x86_64)
Docker 17.09.0-ce

@esabol, nous avons évalué le passage à overlay2 après la mise à niveau vers CentOS 7.4. C'est malheureusement trop de travail. Les partitions que nous pouvions utiliser pour stocker les données sont XFS et avant la version 7.4, l'option de formatage XFS par défaut de CentOS manquait un paramètre (j'ai oublié lequel) pour pouvoir prendre en charge overlay2 en haut. Cela signifie donc que nous devrons reformater la partition afin de pouvoir utiliser overlay2 sur XFS. C'est à ce moment-là que le passage à overlay2 va nous coûter trop de travail pour éviter les temps d'arrêt, et le dernier noyau 7.4 + Docker 17.09 et les recommandations ci-dessus pour la configuration LVM ont beaucoup aidé à éviter le problème la plupart du temps.

Remarque : docker info affiche un gros avertissement indiquant que l'exécution de overlay2 sur XFS sans ces options spécifiques n'est pas prise en charge et sera supprimée dans une future version.

https://github.com/moby/moby/pull/34573 correctif publié dans les versions 17.09.1-ce, 17.12.0-ce

@jcberthon Nous avons récemment mordu la balle et fait la transition vers la superposition2, et je suis tellement content que nous l'ayons fait ! Les performances se sont améliorées de 40% dans les benchmarks de nos tests unitaires qui font docker run --rm . La goutte d'eau pour nous pour devmapper était le numéro 20401. Le passage à overlay2 n'a pas été très difficile, mais nous avons beaucoup d'espace disque libre. J'ai écrit un script pour docker save toutes nos images dans des archives et un autre script pour docker load toutes les archives. Nous avons terminé en 2-3 heures. Je sais que cela semble être un problème et que cela peut être le cas si vous n'avez pas assez d'espace disque, mais cela en vaudra la peine à long terme, je pense. Bonne chance!

Ceci est corrigé dans 17.12.1

Merci a tous.

avant la version fixe, le redémarrage du nœud physique résoudra le problème

@ravilr @KevinTHU concernant votre commentaire https://github.com/moby/moby/issues/27381#issuecomment -277148106 et https://github.com/moby/moby/issues/27381#issuecomment -267547259 J'ai observé que changer le fichier de l'unité docker sur RHEL en PrivateTmp=true résout également le problème. Avez-vous vu quelque chose de similaire?

@MohdAhmad n'a jamais essayé cela, mais je pense que cela peut être ok, car PrivateTmp=true dans le fichier d'unité docker est réservé à docker, peut-être résoudre ce problème mieux encore.

Je trouve le même problème. Parce que j'ouvre le dossier, ferme la fenêtre pour le résoudre.