Moby: Treiber-Devicemapper konnte das Root-Dateisystem nicht entfernen. Gerät ist beschäftigt

Ist das bei jedem Container so? Was läuft im Container und welche Optionen verwenden Sie, um den Container zu starten? (zB verwenden Sie gebundene Verzeichnisse, verwenden Sie docker exec , um zusätzliche Prozesse im Container zu starten?)

Wir führen alle Container auf die gleiche Weise aus und es passiert zufällig auf jedem von ihnen.
Wir verwenden kein docker exec , binden keine Verzeichnisse ein.
Hier ist die Konfiguration eines der toten Container:

[
    {
        "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": ""
                }
            }
        }
    }
]

Mir ist gerade aufgefallen, dass dies nur auf Servern mit diesem Dateisystem passiert Backing Filesystem: ext4
Das Problem scheint nicht auf Servern aufzutreten, auf denen xfs als Backup-Dateisystem ausgeführt wird.

@ceecko danke, das ist interessant

@rhvgoyal ist das ein bekanntes Problem auf Ihrer Seite?

Das trifft uns in der Produktion hart :/ Irgendwelche Hinweise, wie man die toten Container entfernt?

@thaJeztah Seltsam, dass dies nur mit ext4 und nicht mit xfs passiert. Mir ist so etwas nicht bekannt.

Im Allgemeinen haben Leute gemeldet, dass das Gerät ausgelastet ist, und dafür kann es so viele Gründe geben.

@ceeko Stellen Sie zunächst sicher, dass der Docker-Daemon in einem eigenen Slave-Mount-Namespace und nicht in einem Host-Mount-Namespace läuft. Damit Einhängepunkte nicht durchsickern und die Wahrscheinlichkeit, dass solche Fehler auftreten, geringer ist. Wenn Sie einen systemd-gesteuerten Docker verwenden, sollte es eine Docker-Unit-Datei geben und sie sollte MountFlags=slave haben.

@rhvgoyal Das MountFlags=slave scheint das Problem bisher zu lösen. Die vor der Änderung erstellten Container sind immer noch ein Problem, aber neue Container scheinen den Fehler bisher nicht auszulösen. Ich melde mich, falls sich was ändert.

Übrigens kann es sich lohnen, die Dokumentation zum Speichertreiber zu aktualisieren, um dies als bewährte Methode in der Produktion zu empfehlen, da ich keine Referenz finden konnte.

Danke für deine Hilfe.

Dies wurde vor einiger Zeit geändert; https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68 (https://github.com/docker/docker/pull/22806) nicht aktiviert; https://github.com/docker/docker/pull/22806#issuecomment -220043409

Sollen wir die Standardeinstellung wieder ändern? @rhvgoyal

@thaJeztah Ich denke, es könnte eine gute Idee sein, die Standardeinstellung wieder auf MountFlags=slave zu ändern. Das haben wir getan.

Idealerweise sollten die Funktionen für verzögertes Entfernen und verzögertes Löschen dafür gesorgt haben, und es war nicht erforderlich, MountFlags=slave zu verwenden. Eine verzögerte Löschung allein reicht jedoch nicht aus. In alten Kerneln fehlt eine Funktion, mit der man ein Verzeichnis aus einem Mount-Namespace entfernen kann, selbst wenn es in einem anderen Mount-Namespace gemountet ist. Und das ist ein Grund, warum das Entfernen von Containern fehlschlagen kann.

Bis alte Kernel diese Funktion bieten, kann es also eine gute Idee sein, den Docker-Daemon in einem Slave-Mount-Namespace auszuführen.

@rhvgoyal die Fehler traten auch bei MountFlags=slave . Wir versuchen die verzögerte Entfernung und Löschung und werden uns bei Ihnen melden.

Wir haben gerade den gleichen Fehler auch bei xfs erlebt.
Hier sind die Docker-Infos

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

Ich bestätige, dass der Fehler auch bei MountFlags=slave und dm.use_deferred_deletion=true und dm.use_deferred_removal=true immer noch auf 1.12.2 auftritt, wenn auch seltener als zuvor.

Hier sind weitere Informationen aus dem logs re 1-Container, der nicht entfernt werden konnte:

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

Die folgende Meldung weist darauf hin, dass das Entfernen des Verzeichnisses fehlgeschlagen ist.

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

Und in älteren Kerneln kann es fehlschlagen, weil das Verzeichnis in einem anderen Mount-Namespace eingehängt ist. Wenn Sie die Funktion deferred deletion deaktivieren, wird diese Nachricht nicht mehr angezeigt. Aber es wird eine andere Fehlermeldung werden.

Der Kern des Problems hier ist, dass der Container entweder noch läuft oder einige seiner Mount-Punkte in einen anderen Mount-Namespace durchgesickert sind. Und wenn wir herausfinden können, in welchen Mount-Namespace es durchgesickert ist und wie es dorthin gelangt ist, können wir versuchen, es zu reparieren.

Sobald dieses Problem auftritt, können Sie versuchen, find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543" tun

Und dann sehen Sie, welche pids Mounts haben, die sich auf Container beziehen, die in sie durchgesickert sind. Und das könnte eine Idee geben.

Ich habe vier Container ausprobiert, die alle tot sind und nicht entfernt werden können, weil das Gerät beschäftigt ist und nichts hat :/

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

Jetzt bekomme ich tatsächlich eine etwas andere Fehlermeldung:

# 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

Gleiche Sache. Dieses Verzeichnis kann nicht gelöscht werden, da es in einem anderen Mount-Namespace eingehängt ist. Versuchen Sie, in /proc/ zu suchen./mounts und grep für diese ID 527ae5 und sehen, welche pid diesen Mount-Punkt sieht. Wir müssen in Ihrem Setup herausfinden, warum der Container-Rootfs-Mount-Punkt in einen anderen Mount-Namespace leckt.

Auf geht's:

# 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

was verarbeitet diese pids zuordnen? Versuchen Sie es mit cat /proc/<pid>/comm oder ps -eaf | grep <pid>

Dies sind alle nginx-Worker-Prozesse, die nach einem Neuladen der Konfiguration heruntergefahren werden (siehe oben bearbeiteten Kommentar). Ich frage mich, warum sie die Mounts blockieren, da die Container keine Volumes binden.

Der nginx-Prozess läuft also in einem anderen Container? Oder läuft es auf dem Host?

Kannst du folgen.

• ls -l /proc/<docker-daemon-pid>/ns/mnt
• ls -l /proc/<nginx-pid>/ns/mnt
• Führen Sie eine Bash-Shell auf dem Host aus und führen Sie ls -l /proc/$$/ns/mnt

Und Ausgabe einfügen. Hier.

nginx läuft auf dem Host.

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]

Sie scheinen docker-pid und host beide denselben Mount-Namespace zu teilen. Und das bedeutet, dass der Docker-Daemon im Host-Mount-Namespace ausgeführt wird. Und das bedeutet wahrscheinlich, dass nginx irgendwann nach dem Containerstart gestartet wurde und in einem eigenen Mount-Namespace zu laufen scheint. Und zu dieser Zeit sind Mount-Punkte in den nginx-Mount-Namespace durchgesickert und das verhindert das Löschen des Containers.

Bitte stellen Sie sicher, dass MountFlags=slave für Sie funktioniert. Sobald es funktioniert, /proc//ns/mnt gibt unterschiedliche Ausgaben für den Docker-Daemon und die Bash-Shell aus, die im Host-Mount-Namespace ausgeführt werden.

Du hast recht. Dieser Host hat MountFlags=slave noch nicht eingerichtet.
Ein anderer Host tat es jedoch und es gab immer noch tote Container. Ich habe sie jetzt alle manuell entfernt, aber sie wurden mit MountFlags=slave .

Ich warte, bis sich die Situation wiederholt und werde hier ein Update veröffentlichen. Vielen Dank.

Jetzt ist die Situation wie folgt - wir verwenden MountFlags=slave und das verzögerte Entfernen und Löschen und manchmal gibt die Remote-API eine Fehlermeldung aus, dass das Gerät beschäftigt ist und nicht entfernt werden kann. Wenn jedoch docker rm container direkt nach dem Fehler aufgerufen wird, wird der Container problemlos entfernt.

Das Problem ist wieder aufgetaucht.

Dockerd

# 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

Prozesse vom vorherigen Befehl

  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

Okay, docker-containerd-shim sieht diesen Mount-Punkt und hält ihn daher beschäftigt. Ich bin mir nicht sicher, was docker-containerd-shim ist und warum der Mount-Punkt dort undicht ist. Wer weiß davon.

@crosbymichael Sie wissen vielleicht davon.

cc @mrunalp

Danke für den Ping. Ich schau mal nach.

@ceecko können Sie überprüfen, was der Mount-Namespace dieser docker-containerd-shim-Threads / -Prozesse ist. Ich vermute, dass diese den Mount-Namespace nicht mit dem Docker-Daemon teilen und dies wahrscheinlich sollte.

@rhvgoyal Sie teilen den gleichen Namensraum

Dockerd

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

Ich habe drei docker-containerd-shim-Prozesse überprüft

# 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]

Wir haben keine toten Container, die jetzt nicht entfernt werden könnten.
Die Sache ist, dass wir zweimal pro Woche regelmäßig alle Container stoppen und entfernen und neue mit der gleichen Konfiguration starten. Vor diesem "Neustart" sind einige Container tot und können nicht entfernt werden. Nach dem regulären "Neustart" sind die meisten Container tot, aber wenn alle alten Container gestoppt werden, können alle toten Container plötzlich entfernt werden.

Ich habe das gleiche Problem, erhalte aber auch einige zusätzliche Fehler, wenn ich versuche, einen Container mit docker-compose up -d neu zu erstellen:

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"

Insbesondere der Error closing logger: invalid argument Fehler sowie der failed to exit within 10 seconds Fehler, von dem ich mir ziemlich sicher bin, dass er nicht passieren sollte, da ich dumb-init verwende , um meine Container zu starten.

Sind diese Fehler mit diesem Problem verbunden?

Ich arbeite derzeit an einer Lösung dafür. Ich habe eine offene PR in containerd, um zu helfen.

Es ist schwer, eine reproduzierbare Möglichkeit zu finden, dies zu testen. Würde einer von Ihnen nach Abschluss eines Fixes daran interessiert sein, diesen Fix zu testen?

Ja, definitiv. Ich werde versuchen, eine virtuelle Maschine zu erstellen, in der ich dieses Problem reproduzieren kann, und die Fehlerbehebung dort versuchen; Wenn das nicht funktioniert, teste ich es auf dem Server, auf dem die Probleme auftreten.

Ich habe gerade eine VM erstellt und konnte das Problem (ganz einfach!) reproduzieren.

Das habe ich mit Virtualbox gemacht:

1. Installieren Sie eine einfache Arch Linux-VM (mit dem normalen Installationsprozess)
2. Installiere docker, docker-compose und einen anderen Daemon, von dem ich mehrere Prozesse ausführen kann (in diesem Fall habe ich nginx gewählt), dann systemctl enable docker und starte das System neu
3. Konfigurieren Sie nginx für die Ausführung mit 500 Worker-Prozessen
4. Erstellen Sie eine Docker-Compose-Datei mit 3 Containern mit langer Laufzeit (ich wählte Postgres, Tag 9.2)
5. docker-compose up -d
6. systemctl start nginx
7. Ändern Sie die Versionen einiger Container in der docker-compose-Datei, um das Image-Tag 9.3 zu verwenden
8. docker-compose pull
9. docker-compose up -d (es versucht, die Container neu zu erstellen, und gibt mir dann den Fehler "Gerät ist beschäftigt" für beide Container.

Wenn ich nginx anhalte, kann ich die Container entfernen.

docker-compose.yml ab sofort (ich habe das Docker-Setup meines fehlerhaften Systems imitiert):

Ich kann auf Anfrage Zugriff auf die VM gewähren, geben Sie mir einfach eine E-Mail, um die Anmeldung zu senden.

@mlaventure Kann dieses Problem erneut geöffnet werden? Im Moment wissen wir nicht, ob dieses Problem behoben wurde oder nicht.

@SEAPUNK werden wir containerd mit diesem vorgeschlagenen Fix aktualisieren. Wenn Sie die Möglichkeit zum Testen haben, kann ich Ihnen Binärdateien zum Ausprobieren zur Verfügung stellen.

Klar, ich habe meine VM im Standby.

Haben Sie eine Idee, wann die Binärdateien fertig sein werden?

@SEAPUNK Release Candidates für 1.13 sind jetzt zum Testen verfügbar und sollten diese Änderung haben; https://github.com/docker/docker/releases

Okay, ich werde es ausprobieren; Danke!

ich an alle,
Ich glaube, ich habe das gleiche Problem, das hier gemeldet wird

[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

Am Ende musste ich die Binärdatei manuell über PKGBUILD erstellen, da es einfacher ist und ich mit Anpassungen die PKGBUILD zwingen kann, einen bestimmten Container-Commit zu verwenden (den ich auf docker/containerd@03e5862ec0d8d3b3f750e19fca3ee367e13c090e gesetzt habe):

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

Ich sollte bald Ergebnisse der Korrektur haben.

Ich mache vielleicht etwas falsch, aber ich kann jetzt überhaupt keine Container starten:

Oh, ich denke, ich muss runc aktualisieren ... brb rebuilding

Ja, der Fix scheint nicht zu funktionieren:

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

Sofern Sie dies nicht in Ihrer eigenen VM reproduzieren können, bin ich bereit, Zugriff auf meine VM zu gewähren, auf der ich dieses Problem reproduziere, und habe das benutzerdefinierte Docker-Paket erstellt.

Ich sehe dies in Docker 1.12.3 auf 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 Mo 24 Okt 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
dc2-elk-02:/root/staging/ls-helper$ docker rm ls-helper
Fehlerantwort vom Daemon: Treibergerätemapper konnte das Root-Dateisystem nicht entfernen e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: Gerät ist beschäftigt

Ich verwende Docker Compose nicht.

Ich denke, vielleicht stoße ich auch auf diesen Fehler.

Ich sehe viele dieser Fehler, wenn wir Akzeptanztests für Flocker durchführen:

[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
Beim Löschen/Entfernen von gestoppten/toten Containern auf RHEL7.1 mit dockerd 1.12.4 mit verzögertem Löschen und Entfernen aktiviert=true ohne MountFlags in systemd docker.service-Unit-Dateien treten 'Device busy'-Probleme auf.
Sehen Sie auch Kernel-Meldungen wie:
"kernel: device-mapper: Thin: Löschen des Thin-Geräts 120 fehlgeschlagen." (120 ist die Geräte-ID des Thinpool-Geräts des zu entfernenden Containers)

In allen Fällen wurde der Devicemapper-Thinpool-Device-Mount-Punkt für den zu entfernenden Container in den Mount-Namespace einer anderen PID auf dem Host durchgesickert, der mit MountFlag=private/slave gestartet wird.

• ntpd.service wird mit PrivateTmp=true in RHEL gestartet
• Der systemd-udevd-Dienst wird mit MountFlags=slave in RHEL gestartet
  Auf Hosts, auf denen das Löschen von Containern fehlschlägt, wurde einer dieser Prozesse nach der entsprechenden Container-Startzeit neu gestartet.

Es sieht also so aus, als ob es sehr einfach ist, Mount-Punkte im Host-Mount-Namespace zu verlieren, da die oben genannten Systemprozesse standardmäßig einige Mount-Namespaces aufheben, die nicht einzeln geändert/kontrolliert werden können.
Ist das Ausführen von dockerd mit mountflags=slave die einzige Lösung hier? Können Sie mir auch helfen zu verstehen, warum mountflags=slave (und standardmäßig freigegeben) vor einiger Zeit aus der Docker-Systemd-Unit-Datei entfernt wurde.
In welchen Szenarien führt das Ausführen von dockerd mit Slave-Mount-Point-Verbreitung zu anderen Problemen?
Vielen Dank.

Es gibt Unterschiede im RHEL-Kernel und im Upstream-Kernel, die wir zu beheben versuchen, was uns zwingt, den Dockerd in seinem eigenen Mount-Namespace auszuführen, in Fedora funktioniert der Kernel anders, was es uns ermöglicht, den Dockerd im Host-Namespace auszuführen.

@rhvgoyal kann Ihnen die blutigen Details geben.

@ravilr , auf Rhel/Centos-Kerneln, Deaktivieren Sie das verzögerte Löschen. Kernel hat keine Patches, um es zu unterstützen.

Führen Sie Docker auch mit MountFlags=slave aus

Sie können die verzögerte Entfernung weiterhin für Rhel/Centos-Kernel verwenden und das sollte funktionieren.

Übrigens, wenn Sie docker-storage-setup zum Einrichten des Speichers verwenden, wird automatisch festgestellt, ob der zugrunde liegende Kernel verzögertes Löschen unterstützt oder nicht und diese Option entsprechend setzen/deaktivieren.

@rhvgoyal kennen Sie eine Möglichkeit, nach dem fehlgeschlagenen Entfernen des Container-Root-Dateisystems Speicherplatz

@rhvgoyal Danke für die Vorschläge. Ich werde es wie von Ihnen vorgeschlagen versuchen und hier berichten, wenn wir weiterhin Probleme mit dem Entfernen von Containern sehen.

Stoßen; Gibt es weitere Informationen, die Sie benötigen, um das Problem zu lösen?

Ich habe dies selbst mit 1.12.5 auf Centos 7 erreicht.

Das Aktivieren von moutflags=slave sowie das Aktivieren des verzögerten Entfernens und Löschens haben dieses Problem für mich behoben. Jetzt treffe ich auf diesen Race Condition-Bug: https://github.com/docker/docker/issues/23418

Dies ist etwa 100-mal besser, als festsitzende Behälter mit Gewalt entfernen zu müssen, aber immer noch nicht großartig.

Ich kann auf einem CentOS 7 auf xfs reproduzieren.

Gleiches Problem hier, 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

Ist diesbezüglich eine Lösung in Sicht? Ich sehe das Problem immer noch und meine Versuche, den Prozess zu finden, der das Gerät offen hält, sind fehlgeschlagen. Es scheint keine Prozesse zu geben, die das beschäftigte Gerät offen halten.

Vielen Dank.

(Update zu meinem Kommentar: Beim ersten Lesen des Threads war es nicht klar, aber es sieht so aus, als ob das Aktivieren der verzögerten Entfernung und das Setzen von MountFlags=slave das Problem beheben könnte. Ich werde auch Docker auf 1.13 aktualisieren.)

Jemand , der dieses Problem beheben @ravilr oben sehen, Details unten:

In allen Fällen wurde der Devicemapper-Thinpool-Device-Mount-Punkt für den zu entfernenden Container in den Mount-Namespace einer anderen PID auf dem Host durchgesickert, der mit MountFlag=private/slave gestartet wird.

ntpd.service wird mit PrivateTmp=true in RHEL gestartet
Der systemd-udevd-Dienst wird mit MountFlags=slave in RHEL gestartet
Auf Hosts, auf denen das Löschen von Containern fehlschlägt, wurde einer dieser Prozesse nach der entsprechenden Container-Startzeit neu gestartet.

either of these processes were restarted after the corresponding container start time. ist der entscheidende Punkt, die Dateien in einigen Verzeichnissen wie "tmp" werden von anderen Namespaces nicht nur von Docker-Containern verwendet, sodass Docker sie nicht ohne Gewalt beenden kann.
Sie können dieses Problem beheben, indem Sie die neu gestarteten Prozesse stoppen oder ihren systemd-Parameter PrivateTmp=true auf false setzen und sie neu starten.

Referenz: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

@KevinTHU Vielleicht

Aber in meinem Fall (Ubuntu 14.04) muss ich nur den Docker-Dienst selbst neu starten, um dies zu beheben
( service docker restart ). kein "ntpd.service" oder "systemd-udevd service" ist beteiligt.

Ist das sinnvoll?

@quexer natürlich kann ein Neustart von Docker dieses Problem lösen, aber auch der gesamte Container wird neu gestartet, das ist für eine Produktionsumgebung zu teuer

@KevinTHU Neustart des Docker-Dienstes NICHT auf laufende Container aus. Sie können es selbst versuchen.

@quexer Es hängt von Ihrer Konfiguration ab. Ich vermute jedoch, dass das Problem möglicherweise nicht behoben wird, wenn Sie Container im --live-restore Modus laufen lassen.
Standardmäßig stoppt Docker alle Container beim Beenden, und wenn es beim Backup etwas gibt, werden sie auch beendet.

@cpuguy83 @KevinTHU Entschuldigung, es ist meine Schuld. Sie haben Recht, Docker neu starten wird alle Container neu starten.

Ich bekomme das jetzt regelmäßig mit einer meiner VMs aus heiterem Himmel. Interessanterweise wurde einer von ihnen nach mehr als 8 Stunden löschbar, wenn er in Ruhe gelassen wurde. Hier meine 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)

Und es ist wieder kaputt.

Weiß nicht, ob das relevant ist, aber /var/log/messages hat:

14. Feb 16:58:49 vrici Kernel: dev_remove: 40 Callbacks unterdrückt
14. Feb 16:58:54 vrici Kernel: dev_remove: 40 Callbacks unterdrückt
14. Feb 16:58:59 vrici Kernel: dev_remove: 40 Callbacks unterdrückt

Der Fehler ist jetzt:

Fehlerantwort vom Daemon: Treiber Devicemapper konnte das Root-Dateisystem nicht entfernen b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e: Fehler beim Entfernen des Geräts dd81b82c875f4bcef819be83e9344c507965a9e9f685189f08 Busc

Gerät ist irgendwo beschäftigt. Können Sie nach dem Fehler folgendes Skript versuchen und sehen, wo das Gerät beschäftigt sein könnte.

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

./find-busy-mnt.sh

./find-busy-mnt.sh dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde681

rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
Keine pids gefunden
rlpowell@vrici> sudo docker rm freq_build
Fehlerantwort vom Daemon: Treiber-Devicemapper konnte das Root-Dateisystem nicht entfernen b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10: Fehler beim Entfernen des Geräts

Oh, sieht so aus, als ob das der falsche Hash war.

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

Das ist ... extrem seltsam. Ich habe keine Ahnung, warum ein völlig unabhängiger php-fpm-Prozess vom Kernel so gesehen wird, dass er diese Mounts offen hält.

@rlpowell Ja, das ist das ganze Problem hinter diesem Problem. Etwas führt dazu, dass Mount-Namespace nicht richtig funktioniert.

Ich habe hier einen funktionierenden Workaround gefunden:

Dies bedeutet im Wesentlichen, dass Sie Ihrer systemd docker.service-Datei die folgende Zeile hinzufügen:
MountFlags=privat

Dies scheint zu funktionieren, zumindest für die kleine Stichprobe von Docker-Ausführungen, die ich seit der Bereitstellung durchgeführt habe. Es wäre gut, wenn jemand, der Docker vollständig versteht, die Konsequenzen dieses Flags erklären könnte. Ich vermute, dass nach dem Start von Docker gemountete Dateisysteme möglicherweise nicht für Container verfügbar sind, aber ich weiß es ehrlich gesagt nicht. Unsere Konfiguration ist für die Verwendung auf einem Build-Server gedacht und dort scheinen die Dinge gut zu funktionieren.

Ein ziemlich großes Problem, das Docker auf Centos 7 / RHEL effektiv unbrauchbar macht - (und seit 4 Monaten geöffnet?)
Irgendeine ETA?

Das neueste RHEL/centos sollte mit MountFlags=slave in der Datei docker.service ausgeliefert werden.

@rhvgoyal das ist nicht der Fall: https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm

Dies ist auf Branch Master, aber die Branch 1.13.x und 17.03.x haben es auch nicht.

Soweit ich das beurteilen kann, war dieses Flag in einem früheren Servicegerät, wurde aber entfernt. Aber ich fand nicht warum. Vielleicht lösen diese Flags das aktuelle Problem, verursachen aber andere Probleme.

@rlpowell @SEAPUNK scheint dies bei meiner Ubuntu-Installation nicht der Fall zu sein:

$ 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

Ich habe einen Artikel geschrieben, in dem erklärt wird, warum RHEL7 --live-restore bis RHEL7.4 nicht unterstützen kann und warum Docker in einem anderen Mount-Namespace als dem Host ausgeführt werden sollte.

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

+1 Ich möchte mit einem anderen Mount-Namespace laufen und alle Docker-Mounts privat machen.
Es gibt jedoch einige knifflige Stellen.

Wenn der Upstream-Docker kein geeignetes Flag für die Ausführung in MountFlags=slave hat, ist dies ein Fehler und führt leicht zu Problemen mit Mount-Namespaces, die zwischen Containern und Host lecken, und kann zu Problemen beim Entfernen von Container-Images führen.

FWIW, das MountFlags=slave wurde in https://github.com/docker/docker/pull/22806 nach Überprüfung durch die Red Hat-Betreuer entfernt, aber es sieht so aus, als ob es Probleme verursacht, also frage ich mich, ob das rückgängig gemacht werden sollte bis RHEL7.4?

Ja, wir hatten es entfernt und später verursachte es Probleme, also schlossen wir in einem der Diskussionsthreads, dass wir es wieder einführen sollten. Ich dachte, du hättest es schon getan. Weiß aber nicht mehr, welcher Thread das war.

@thaJeztah Yup wir haben uns geirrt und zusätzliche Probleme gefunden.

Und diese Probleme waren in erster Linie spezifisch für ältere Kernel. Neuere Kernel funktionieren einwandfrei.

Lassen Sie mich eine PR eröffnen, um Optionen zu besprechen

PR öffnete hier; https://github.com/docker/docker/pull/31490

gleiches Problem Docker 1.10.3 CentOS Linux Release 7.2.1511
dmesg：
[1732917.246900] device-mapper: ioctl: Docker für geöffnetes Gerät kann nicht entfernt werden-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78
Mitteilungen:
03.04. 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346374677+08:00" level=error msg="Fehler beim Entfernen der eingebundenen Schicht b0b1e839f366086fd7cff564feee385a3aed71a56db90e72c04165217d: Device "
3. Apr 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346597095+08:00" level=error msg="Handler für DELETE /v1.22/containers /b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2d hat einen Fehler zurückgegeben: Treiber-Devicemapper konnte das Root-Dateisystem nicht entfernen b0b1e839f366086fd7cff564feee385a3aed71a56db17e4c041

montieren:
finde /proc/*/mounts | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
/ Proc / 159.779 / Mounts: / dev / Mapper / Andockfensters-8: 3-5.242.884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / export / Andockfensters / Device Mapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 xfs rw, relatime, nouuid, attr2, inode64, logbsize = 64K, Sunit = 128, Breite=128,keine Quote 0 0
/ Proc / 159.806 / Mounts: / dev / Mapper / Andockfensters-8: 3-5.242.884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / export / Andockfensters / Device Mapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 xfs rw, relatime, nouuid, attr2, inode64, logbsize = 64K, Sunit = 128, Breite=128,keine Quote 0 0
neuer Behälter:
docker inspizieren 8777d36c94ec|grep Pid
"Pid": 159779,

//mein Fehler，habe es gelöst 。

Was ist die ID "8777d36c94ec"? Ist dies die Container-ID des zu entfernenden Containers oder ein anderer Container?

Das Gerät ist also beschäftigt, weil es noch im Container gemountet ist. Also hat keiner der Container, die entfernt werden, noch aufgehört. Oder wenn es sich um einen anderen Container handelt, sollte er in einem anderen Container nicht sichtbar sein.

Nicht sicher, was der Mount-Punkt "/export/docker/devicemapper/mnt/..." ist und wer das erstellt hat?

Auf meinem Mint-System führt ein Upgrade von 17.03.1~ce-0~ubuntu-xenial auf 17.04.0~ce-0~ubuntu-xenial dass dieses Problem sehr häufig auftritt.

Vor dem Upgrade war ich noch nie darauf gestoßen. Nach dem Upgrade war es sehr häufig. Ein Downgrade zurück auf 17.03.1 scheint das Problem gelöst zu haben.

Nur als Hinweis für andere, die diesen Thread lesen: Wenn Sie cAdvisor von Google ausführen, wird dieses Problem beim Versuch, einen Container zu entfernen, auftreten. Zuerst müssen Sie cAdvisor stoppen, dann den Container entfernen und dann cAdvisor erneut starten.

@bmbroom Dito . Wir betreiben Build-Server auf Basis von Ubuntu, die den ganzen Tag Container ablaufen lassen (normalerweise von docker-compose gesteuert), und wir hatten dieses Problem ein paar Mal pro Woche gesehen. Die Server sind eine Mischung aus Trusty und Xenials. Wir haben vor kurzem mit dem Upgrade auf 17.04.0~ce begonnen und sehen dies jetzt mehrmals am Tag.

Mir ist nicht klar, ob MountFlags=slave auf Ubuntu anwendbar ist, aber das versuche ich als nächstes.

@rhvgoyal
Entschuldigung, das war mein Fehler.
andere sind noch in meinem Container montiert。

Hatte gerade das gleiche Problem bei:

• Docker: Docker-Version 17.03.1-ce, Build c6d412e
• Betriebssystem: Red Hat Enterprise Linux Server-Version 7.3 (Maipo)
• Kernel: 3.10.0-514.6.1.el7.x86_64
• ntpd: 4.2.6p5

Das Ausführen von systemctl restart ntpd das Problem sofort behoben.

@xeor
Was ist Ihre MountFlags in der docker.service-Unit-Datei?

Es gibt kein MountFlags in meiner /usr/lib/systemd/system/docker.service Datei, aber systemctl show docker zeigt MountFlags=0 .

Das gleiche gilt für ntpd.service . Das hat auch die PrivateTmp=true unter der [Service] Strophe (falls das wichtig ist).

Führen Sie vorerst mit MountFlags=slave aus.

@rhvgoyal hat meine docker.service-Datei überprüft. Aber Ihr Wert ist bereits festgelegt:

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

mit dem neuesten Redhat (3.10.0-514.16.1.el7)/docker (1.12.6-16.el7)

Was ist mit MountFlags=private? Können Sie den Unterschied zwischen Privat und Sklave erklären?

Ich sehe dieses Problem derzeit auf RHEL/CentOS 7.3, Kernel 3.10.0-514.16.1.el7.x86_64, mit Docker-Version 17.05.0-ce, Build 89658be. Wir haben dieses Problem im Laufe des letzten Jahres immer wieder beobachtet.

Wir haben auch keine MountFlags-Option in /etc/systemd/system/multi-user.target.wants/docker.service. Sollen wir dort "MountFlags=slave" hinzufügen?

Ich sehe Kommentare, die besagen, dass dieses Problem in Centos, RHEL und Ubuntu auftritt. Sind andere Betriebssysteme vor diesem speziellen Problem sicher, wie Debian oder ContainerLinux oder SUSE?

@earwax Alles mit einem neueren Kernel (>= 3.15) sollte im Allgemeinen besser funktionieren.
Es gibt jedoch immer Situationen, die Sie erstellen können, in denen dieser Fehler auftritt.
Außerdem sind in den Kommentaren hier mehrere Möglichkeiten aufgeführt, um dies zu mildern.

Ich sehe dieses Problem bei SUSE ... konnte aber keine Lösung dafür finden ... Ich sehe, dass dies hauptsächlich beim Anbieter AZURE passiert

Wir finden dieses Problem auch, als wir Dockerd von 1.12.6 auf 17.05 aktualisiert haben. Alle alten Container konnten ohne '-f' nicht gelöscht werden, diese Container hatten ein gemeinsames Merkmal, dass sie nicht alle gestoppt wurden, wenn wir dockerd aktualisieren, weil wir die '--live-restore'-Konfiguration haben. Ich denke, hier gibt es einige Probleme.

Dies ist in 17.06, FYI, immer noch ein Problem, zumindest mit CentOS 7.

@MGD1981 Dieser Fehler muss behoben werden, wir verwenden Centos 7 genauso und wir stellen fest, dass nicht nur die alten Container, die vor der Aktualisierung des Dockers erstellt wurden, das Problem "Gerät ist beschäftigt" haben, sondern auch die neu erstellten Container. Dies ist wirklich kritisch , und wir umgehen es, indem wir docker.service "MountFlags=slave" hinzufügen. Wir wissen jedoch nicht, ob dieser Parameter ein anderes Problem mit sich bringt.

Ja, probiere das jetzt in unserer QA-Umgebung aus. Werde genau aufpassen
zu den Halterungen. Besteht potenziell ein Risiko für den FS eines Containers?
"vergessen" mit dieser Einstellung, den Host mit der Zeit mit Festplatten füllen
von toten Containern?

Am Mo, 3. Juli 2017, 22:38 PM schrieb KevinTHU [email protected] :

@MGD1981 https://github.com/mgd1981 Dieser Fehler muss behoben werden, wir sind
mit centos 7 das gleiche, und wir finden heraus, dass nicht nur die alten container
erstellt vor dem Aktualisieren des Dockers haben das Problem "Gerät ist beschäftigt", aber auch das
neu erstellte Container, das ist wirklich kritisch, und wir umgehen es, indem wir
Hinzufügen von "MountFlags=slave" zu docker.service. Allerdings wissen wir nicht ob
Dieser Parameter bringt ein anderes Problem mit sich.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/27381#issuecomment-312766596 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.

@MGD1981 Ja, es scheint Festplatten auf dem Host zu geben, die nicht mehr verwendet werden. Siehe #33025

@ceecko Dies sollte ab dem

@cpuguy83 schön! Wird es auch alte Festplatten bereinigen, die von früheren Versionen übrig geblieben sind?

@cpuguy83 ist

@ravilr Es ist raus. Veröffentlichungen kommen von github.com/docker/docker-ce.

@ceecko glaube ich nicht.

@cpuguy83 danke. die Versionshinweise für 17.06 scheinen keine Pr-Fixes zu diesem Problem zu erwähnen. was war die Lösung, um dies zu beheben? Danke noch einmal.

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

Ich verwende 17.06.0-ce auf CentOS 7 (mit Thin-Pool-Speicher) und dies passiert in letzter Zeit häufig.

+ 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

Ist das mit oder ohne MountFlags=slave , @AaronDMarasco-VSI ? CentOS 7.3?

17.06 behebt das grundlegende Problem nicht, es ist nur besser darin, damit umzugehen.
Ich überprüfe, ob Docker (oder eine Unterkomponente wie containerd) das Problem verschlimmert.

@esabol Nein... privat?

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) 

Nun, @AaronDMarasco-VSI, ich würde empfehlen, das in MountFlags=slave ändern, was die Situation für uns verbessert hat, aber wir sind immer noch am 17.05 und ich glaube, ich habe etwas gesehen, das Sie nicht verwenden möchten MountFlags=slave mit dm.use_deferred_removal ? Vielleicht kommentiert und bestätigt noch jemand.

Ich verwende Docker 17.03 auf Centos 7.3 und Kernel 4.10. und ich habe diesen Fehler viel gesehen. Unten finden Sie einige weitere Details zu MountFlag.

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

gleiches Problem hier mit Debian 8. es bricht unser CI, irgendwelche möglichen Workarounds??

@thg303 versuche, wenn möglich, deinen Dockerdeamon herunterzufahren und versuche das Root-Dateisystem zu bereinigen/zu entfernen, das in deiner Logdatei (rm /var/lib/docker/..... ) vorkommt. Du solltest aber vorher einen Snapshot/Backup machen :-)

Gleiches Problem hier mit Fedora 25, Kernel 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.

Ich habe dieses Problem jedes Mal, wenn Docker auf centos7 aktualisiert wird. Ich starte Docker neu und dann funktioniert alles.

Das gleiche gilt für mich auf Fedora 26 mit Docker 17.06.0-ce. Ein Neustart von Docker hat das Problem nicht behoben.

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

Kommt jetzt ernsthaft ein Jahr und dieser Fehler ist immer noch da?

@NeckBeardPrince Bitte
Wenn Sie helfen möchten, es zu lösen, großartig. Wenn Sie weitere Daten zu dem Problem melden möchten, großartig.

Abgesehen davon gibt es ein paar Möglichkeiten, dieses Problem zu umgehen, die hier gepostet wurden.

systemd-Unit-Datei wird nicht mit 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

Als ich das letzte Mal dieses Problem hatte, waren es ntpd , die die Reittiere hielten.
Heute hatte ich das gleiche Problem, und diesmal war es eine mariadb Instanz, die auf dem Host lief, die der Grund war.

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

Beispiel für das Finden des Procs, der die Reittiere hält....

# 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

Nach dem Neustart von mariadb hat es die Mountpoints losgelassen, aber es hat beim Start viele davon gepackt.

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

Die meisten Fehler beim Entfernen sind darauf zurückzuführen, dass der Mount-Punkt (daher device ) in einigen anderen Mount-Namespaces ausgelastet ist. Ich denke, die folgende vorgeschlagene PR wird bei diesem Problem helfen, wenn der Kernel neu genug ist.

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

Wenn Sie einen alten Kernel verwenden, haben wir einen Plug-In-Aufruf oci-umount geschrieben, um Probleme mit Mount-Leaks zu reduzieren.

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

@rhvgoyal Haben Sie einen Plan, in welche Docker-Version diese PR aufgenommen werden soll? Wir haben es immer noch regelmäßig mit den driver "devicemapper" failed to remove root filesystem zu tun.

CentOS Linux-Version 7.4.1708 (Kern)
3.10.0-693.5.2.el7.x86_64
17.06.2-ce

SIEHT AUS, WIE ES ENDLICH BEHOBEN IST

Wir verwenden Docker Version 17.09.0-ce und haben immer noch das gleiche Problem.

Wir treten gelegentlich auf dieses Problem unter Oracle Linux: mit Docker-Version 17.03.1-ce (aus den Repos von Oracle) auf.

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

Das oben Genannte wird durch die TDA des Projekts festgelegt, sodass wir vorerst nichts davon ändern können.

90 % unserer anderen Umgebungen sind Centos 7.3/7.4, und wir haben das Problem dort nicht gesehen.

Es ist gerade gelungen, eine Instanz dieses Problems mit Docker 17.05 unter arch Linux auf 4.11.9 zu lösen
von

1. docker rm -f [myContainer] (wie üblich mit driver "devicemapper" failed to remove root filesystem fehlgeschlagen)
2. ls /var/lib/docker/devicemapper/mnt/

Dadurch verschwand der Container schließlich (nicht sicher warum).

@MonsieurWave So unglaublich es aussieht, der "ls"

Das docker rm -f [container] meldet einen Fehler, bereinigt aber schließlich den Container und das Dateisystem. Der Befehl ls ist ein Ablenkungsmanöver, Sie müssen nur ein paar Sekunden warten. Aber besser als das ist MountFlags=slave . Und am besten ist es, den Devicemapper auszuschalten und stattdessen overlay2 zu verwenden.

Und am besten ist es, den Devicemapper auszuschalten und stattdessen overlay2 zu verwenden.

Wir verwenden Docker auf CentOS 7.x (derzeit bei 7.4) seit über einem Jahr. Als wir Docker zum ersten Mal installierten, sagte alles und jeder, dass Sie Devicemapper mit direct-lvm verwenden müssen, um die beste Leistung und Stabilität zu erzielen. https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ sagt immer noch, dass Sie Devicemapper auf CentOS mit Docker EE verwenden müssen. Glücklicherweise verwenden wir Docker CE, sodass wir auf Overlay2 umsteigen konnten. Ich habe das Gefühl, dass die Docker-Leute bei der Änderung der Standardeinstellung von Devicemapper zu Overlay2 auf CentOS in v1.13.0/1 mit wenig Fanfare oder Diskussion gerutscht sind. Gibt es solide Informationen zur Leistung/Stabilität von Overlay2 im Vergleich zu Devicemapper (direct-lvm) auf CentOS 7? Beim googeln habe ich nicht viel gefunden....

Wir hatten eine sehr schlechte Zeit mit den auf Lager befindlichen CentOS 7.2-Kernels (ihrem 3.10.x frankenstein). Viele Abstürze. Wir haben Kubernetes in einer Entwicklungsumgebung ausgeführt, daher war die Abwanderung unserer Container sehr hoch, aber selbst in relativ leisen Installationen fanden wir die Standard-CentOS+Overlay-Kombination sehr instabil. Das Ausführen eines 4.10+ Upstream-Kernels mit Overlay2 ist viel besser. Habe keine neuere CentOS-Version ausprobiert.

Sie müssen entweder ein zugrunde liegendes Dateisystem verwenden, das ext4 oder XFS-formatiert mit "-n ftype=1" ist. Docker wird ausgeführt, wenn Sie ein falsch formatiertes XFS haben, aber die Ergebnisse sind unvorhersehbar.

Ja, ich bin seit langem auf overlay2 umgestiegen und empfehle jedem, der immer noch devicemapper verwendet, der overlay2 verwenden kann, um zu wechseln , da ich, abgesehen von diesem Problem, gelesen habe, dass Devicemapper ein sehr schlechter Speichertreiber für Docker im Allgemeinen ist.

Das Neustarten von ntpd hat das Problem behoben, das ich hatte ... so verwirrend. Gibt es eine "empfohlene" daemon.json-Konfiguration für Docker auf Centos7?

Einige Verbesserungen kommen in der Pipeline.

Insbesondere das Problem mit diesen anderen Systemdiensten scheint eine Race Condition beim Einrichten von Mount-Namespaces (für diese anderen Systemdienste) und dem Versuch von Docker zu sein, seine eigenen Mounts privat zu halten ... Container, leider verursacht es an anderer Stelle Lecks und hält tatsächlich private Verweise auf diese Mountpoints, was bedeutet, dass sie in diesen Namespaces nicht ausgehängt werden können, außer entweder manuell oder wenn der Prozess neu gestartet wird.

Darüber hinaus gab es in letzter Zeit einige Änderungen, um Race-Bedingungen bei der Verwendung von MS_PRIVATE-Mount-Propagation sowohl in runc als auch in docker zu behandeln.
Wird die nächste Version perfekt sein? Wahrscheinlich nicht... aber ich erwarte, dass es besser wird.

Ich habe genau dasselbe wie @ceecko mit docker 12.1.1 , jetzt keine Chance zum Aktualisieren. Wird es später irgendwo behoben? Schnelle Lösung besteht darin, Prozesse zu beenden und den Docker-Dienst neu zu starten, aber..

Diese Versionen beheben das Problem für mich vollständig, einschließlich --live-restore

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

@esabol Wir haben die Umstellung auf Overlay2 nach dem Upgrade auf CentOS 7.4 evaluiert. Es ist leider zu viel Arbeit. Die Partitionen, die wir zum Speichern der Daten verwenden könnten, sind XFS und vor 7.4 hat die Standard-XFS-Formatierungsoption von CentOS einen Parameter (ich habe vergessen, welchen) übersehen, um Overlay2 oben unterstützen zu können. Das bedeutet, dass wir die Partition neu formatieren müssen, um Overlay2 über XFS verwenden zu können. Dann wird uns der Wechsel zu Overlay2 zu viel Arbeit kosten, um Ausfallzeiten zu vermeiden, und der neueste 7.4-Kernel + Docker 17.09 und die obigen Empfehlungen für die LVM-Konfiguration haben viel dazu beigetragen, das Problem die meiste Zeit zu vermeiden.

Hinweis: docker info zeigt eine große Warnung an, dass das Ausführen von Overlay2 über XFS ohne diese speziellen Optionen nicht unterstützt wird und in einer zukünftigen Version entfernt wird.

https://github.com/moby/moby/pull/34573 Fix veröffentlicht in den Versionen 17.09.1-ce, 17.12.0-ce

@jcberthon Wir haben vor kurzem in den docker run --rm verbesserte sich die Leistung um 40 %. Der letzte Strohhalm für uns für Devmapper war Ausgabe #20401. Der Wechsel zu Overlay2 war nicht sehr schwer, aber wir haben viel freien Speicherplatz. Ich habe ein Skript für docker save alle unsere Bilder in Tarballs geschrieben und ein weiteres Skript für docker load alle Tarballs. Wir waren in 2-3 Stunden fertig. Ich weiß, es scheint mühsam zu sein und kann es sein, wenn Sie nicht genügend Speicherplatz haben, aber es wird sich auf lange Sicht lohnen, denke ich. Viel Glück!

Dies ist in 17.12.1 behoben

Danke an alle.

vor der gefixten Veröffentlichung wird das Problem durch einen Neustart des physischen Knotens behoben

@ravilr @KevinTHU zu Ihrem Kommentar https://github.com/moby/moby/issues/27381#issuecomment -277148106 und https://github.com/moby/moby/issues/27381#issuecomment -267547259 Ich habe beobachtet dass das Ändern der Docker-Unit-Datei auf RHEL in PrivateTmp=true das Problem ebenfalls behebt. Gibt es eine Chance, dass Sie etwas Ähnliches gesehen haben?

@MohdAhmad habe das noch nie versucht, aber ich denke, das ist vielleicht in Ordnung, da PrivateTmp=true in der Docker-Unit-Datei nur für Docker gedacht ist, kann dieses Problem vielleicht sogar besser behoben werden.

Ich finde das gleiche Problem. Da ich den Ordner öffne, schließe das Fenster, um es zu lösen.