Moby: Devicemapper driver gagal menghapus sistem file root. Perangkat sedang sibuk

Apakah ini terjadi dengan wadah apa pun? Apa yang berjalan di wadah, dan opsi apa yang Anda gunakan untuk memulai wadah? (misalnya apakah Anda menggunakan direktori yang dipasang di bind, apakah Anda menggunakan docker exec untuk memulai proses tambahan dalam wadah?)

Kami menjalankan semua kontainer dengan cara yang hampir sama dan itu terjadi secara acak pada salah satu dari mereka.
Kami tidak menggunakan docker exec , jangan mengikat-mount direktori apa pun.
Berikut konfigurasi salah satu wadah mati:

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

Saya baru saja memperhatikan bahwa ini hanya terjadi pada server dengan sistem file ini Backing Filesystem: ext4
Masalah ini tampaknya tidak terjadi pada server yang menjalankan xfs sebagai sistem file pendukung.

@ceecko terima kasih, itu menarik

@rhvgoyal apakah ini masalah yang diketahui di pihak Anda?

Ini sangat memukul kami dalam produksi:/ Adakah petunjuk bagaimana cara mengeluarkan wadah yang mati?

@thaJeztah Aneh bahwa ini hanya akan terjadi dengan ext4 dan bukan xfs. Saya tidak mengetahui hal seperti itu.

Secara umum orang telah melaporkan perangkat sedang sibuk dan ada banyak alasan untuk itu.

@ceeko pertama-tama pastikan docker daemon berjalan ke namespace mount slave sendiri dan bukan host mount namespace. Sehingga mount point tidak bocor dan kemungkinan mendapatkan error seperti itu lebih kecil. Jika Anda menggunakan buruh pelabuhan yang digerakkan oleh systemd, harus ada file unit buruh pelabuhan dan harus memiliki MountFlags=slave.

@rhvgoyal MountFlags=slave tampaknya menyelesaikan masalah sejauh ini. Wadah yang dibuat sebelum perubahan masih menjadi masalah tetapi penampung baru tampaknya tidak memicu kesalahan sejauh ini. Saya akan menghubungi Anda jika ada perubahan.

Btw mungkin perlu memperbarui dokumen driver penyimpanan untuk merekomendasikan ini sebagai praktik terbaik dalam produksi karena saya tidak dapat menemukan referensi apa pun.

Terima kasih untuk bantuannya.

Ini diubah beberapa waktu lalu; https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68 (https://github.com/docker/docker/pull/22806), per diskusi, penghapusan yang ditangguhkan ini mungkin menjadi masalah tidak diaktifkan; https://github.com/docker/docker/pull/22806#issuecomment -220043409

Haruskah kita mengubah default kembali? @rhvgoyal

@thaJeztah Saya pikir mungkin ide yang baik untuk mengubah default kembali ke MountFlags=slave. Kami telah melakukan itu.

Idealnya fitur penghapusan yang ditangguhkan dan penghapusan yang ditangguhkan seharusnya sudah menangani hal ini dan tidak perlu menggunakan MountFlags=slave. Tetapi penghapusan yang ditangguhkan saja tidak cukup. Kernel lama tidak memiliki fitur di mana seseorang dapat menghapus direktori dari namespace mount bahkan jika itu dipasang di namespace mount yang berbeda. Dan itulah salah satu alasan penghapusan kontainer bisa gagal.

Jadi sampai kernel lama menawarkan fitur itu, mungkin ide yang baik untuk menjalankan daemon buruh pelabuhan di namespace mount budak.

@rhvgoyal kesalahan mulai muncul lagi bahkan dengan MountFlags=slave . Kami akan mencoba penghapusan dan penghapusan yang ditangguhkan dan akan menghubungi Anda kembali.

Kami baru saja mengalami kesalahan yang sama pada xfs juga.
Berikut info buruh pelabuhan

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

Saya mengkonfirmasi bahwa kesalahan masih terjadi pada 1.12.2 bahkan dengan MountFlags=slave dan dm.use_deferred_deletion=true dan dm.use_deferred_removal=true meskipun lebih jarang dari sebelumnya.

Berikut info lebih lanjut dari log re 1 container yang tidak dapat dihapus:

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

Pesan berikut menunjukkan bahwa penghapusan direktori gagal.

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

Dan di kernel yang lebih lama itu bisa gagal karena direktori dipasang di beberapa namespace mount lainnya. Jika Anda menonaktifkan fitur deferred deletion , pesan ini akan berhenti datang. Tapi itu akan menjadi beberapa pesan kesalahan lainnya.

Inti masalahnya di sini adalah bahwa wadah masih berjalan atau beberapa titik pemasangannya bocor ke beberapa ruang nama pemasangan lainnya. Dan jika kami dapat mengetahui mount namespace mana yang bocor dan bagaimana itu sampai di sana, kami dapat mencoba memperbaikinya.

Setelah Anda mengalami masalah ini, Anda dapat mencoba melakukan find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543"

Dan kemudian lihat pid mana yang memiliki tunggangan terkait dengan wadah yang bocor ke dalamnya. Dan itu mungkin memberikan beberapa ide.

Saya telah mencoba empat wadah yang semuanya mati dan tidak dapat dilepas karena perangkat sedang sibuk dan tidak mendapatkan apa-apa :/

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

Sekarang saya mendapatkan pesan kesalahan yang sedikit berbeda:

# 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

Hal yang sama. direktori ini tidak dapat dihapus karena sudah terpasang di beberapa namespace mount lainnya. Coba cari di /proc//mounts dan grep untuk id ini 527ae5 dan lihat pid mana yang melihat titik mount ini. Kami perlu mencari tahu bahwa dalam pengaturan Anda mengapa titik mount rootfs container bocor ke namespace mount lainnya.

Ini dia:

# 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

ke proses apa pids ini dipetakan? Coba cat /proc/<pid>/comm atau ps -eaf | grep <pid>

Ini semua adalah proses pekerja nginx yang dimatikan setelah konfigurasi ulang (lihat komentar yang diedit di atas). Saya bertanya-tanya mengapa mereka memblokir tunggangan karena wadah tidak mengikat volume apa pun.

Jadi proses nginx sedang berjalan di wadah lain? Atau sedang berjalan di host?

Bisakah Anda melakukan yang berikut.

• ls -l /proc/<docker-daemon-pid>/ns/mnt
• ls -l /proc/<nginx-pid>/ns/mnt
• Jalankan bash shell di host dan jalankan ls -l /proc/$$/ns/mnt

Dan tempel keluaran. di sini.

nginx berjalan di 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]

Anda docker-pid dan Host keduanya tampaknya berbagi namespace mount yang sama. Dan itu berarti daemon buruh pelabuhan berjalan di host mount namespace. Dan itu mungkin berarti bahwa nginx dimulai di beberapa titik setelah wadah dimulai dan tampaknya berjalan di namespace mount-nya sendiri. Dan pada saat itu mount point bocor ke nginx mount namespace dan itu mencegah penghapusan container.

Pastikan MountFlags=slave bekerja untuk Anda. Setelah berhasil, /proc//ns/mnt akan memberikan output yang berbeda untuk daemon docker dan bash shell yang berjalan di host mount namespace.

Kamu benar. Host ini belum menyiapkan MountFlags=slave .
Tuan rumah yang berbeda melakukannya dan masih ada wadah yang mati. Saya menghapus semuanya secara manual sekarang, tetapi mereka dibuat dengan MountFlags=slave .

Saya akan menunggu sampai situasinya berulang dan akan memposting pembaruan di sini. Terima kasih.

Sekarang situasinya adalah sebagai berikut - kami menggunakan MountFlags=slave dan penghapusan dan penghapusan yang ditangguhkan dan terkadang API jarak jauh memunculkan kesalahan bahwa perangkat sedang sibuk dan tidak dapat dihapus. Namun ketika docker rm container dipanggil tepat setelah kesalahan, ia menghapus wadah dengan baik.

Isu itu muncul lagi.

buruh pelabuhan

# 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

Proses dari perintah sebelumnya

  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

Oke, jadi docker-containerd-shim melihat titik pemasangan ini dan karenanya membuatnya sibuk. Saya tidak yakin apa itu docker-containerd-shim dan mengapa titik mount bocor di sana. Siapa yang tahu tentang itu.

@crosbymichael Anda mungkin tahu tentang itu.

cc @mrunalp

Terima kasih untuk pingnya. Aku akan melihatnya.

@ceecko dapatkah Anda memeriksa apa mount namespace dari utas/proses docker-containerd-shim ini. Saya menduga ini tidak berbagi mount namespace dengan daemon buruh pelabuhan dan mungkin seharusnya.

@rhvgoyal Mereka berbagi namespace yang sama

buruh pelabuhan

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

Saya memeriksa tiga proses docker-containerd-shim

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

Kami tidak memiliki wadah mati yang tidak dapat dipindahkan sekarang.
Masalahnya adalah dua kali seminggu kami secara teratur menghentikan & menghapus semua wadah dan memulai yang baru dengan konfigurasi yang sama. Sebelum "memulai ulang" ini, beberapa wadah akhirnya mati dan tidak dapat dilepas. Setelah "restart" biasa, sebagian besar kontainer mati, tetapi ketika semua kontainer lama dihentikan, semua kontainer mati bisa tiba-tiba dipindahkan.

Saya memiliki masalah yang sama, tetapi saya juga mendapatkan beberapa kesalahan tambahan ketika saya mencoba membuat ulang wadah dengan docker-compose up -d :

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

Secara khusus, kesalahan Error closing logger: invalid argument , serta kesalahan failed to exit within 10 seconds , yang saya yakin seharusnya tidak terjadi karena saya menggunakan dumb-init untuk memulai container saya.

Apakah kesalahan ini terkait dengan masalah ini?

Saat ini saya sedang mengerjakan perbaikan untuk ini. Saya memiliki PR terbuka di containerd untuk membantu.

Sulit untuk menemukan cara yang dapat direproduksi untuk menguji ini, jadi setelah saya menyelesaikan perbaikan, apakah salah satu dari Anda tertarik untuk menguji perbaikan ini?

Ya tentu saja. Saya akan mencoba membuat mesin virtual di mana saya dapat mereproduksi masalah ini, dan mencoba memperbaikinya di sana; jika itu tidak berhasil, maka saya akan mengujinya di server tempat saya mengalami masalah.

Saya baru saja membuat VM dan saya dapat (dengan mudah!) mereproduksi masalah tersebut.

Inilah yang saya lakukan dengan Virtualbox:

1. Instal VM Arch Linux biasa (menggunakan proses instalasi normal)
2. Instal docker, docker-compose, dan daemon lain yang dapat saya jalankan beberapa prosesnya (dalam hal ini, saya memilih nginx), lalu systemctl enable docker , dan reboot sistem
3. Konfigurasikan nginx untuk dijalankan dengan 500 proses pekerja
4. Buat file komposisi buruh pelabuhan dengan 3 wadah yang sudah berjalan lama (saya memilih postgres, tag 9.2)
5. docker-compose up -d
6. systemctl start nginx
7. Ubah versi beberapa wadah di dalam file komposisi buruh pelabuhan untuk menggunakan tag gambar 9.3
8. docker-compose pull
9. docker-compose up -d (ini mencoba membuat ulang wadah, dan kemudian memberi saya kesalahan "Perangkat Sibuk" untuk kedua wadah.

Menghentikan nginx memungkinkan saya menghapus wadah.

docker-compose.yml sampai sekarang (saya meniru pengaturan buruh pelabuhan sistem saya yang gagal):

Saya dapat memberikan akses ke VM berdasarkan permintaan, cukup beri saya email untuk mengirim login.

@mlaventure Bisakah masalah ini dibuka kembali? Saat ini kami tidak tahu apakah masalah ini telah diperbaiki atau belum.

@SEAPUNK kami akan memperbarui containerd dengan perbaikan yang diusulkan ini. Jika Anda memiliki kesempatan untuk menguji, saya dapat memberi Anda binari untuk dicoba.

Tentu, saya memiliki VM saya dalam keadaan siaga.

Adakah ide kapan binari akan siap?

Kandidat rilis https://github.com/docker/docker/releases

Baiklah, saya akan mencobanya; Terima kasih!

saya untuk semua,
Saya pikir saya mengalami masalah yang sama yang dilaporkan di sini

[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

Saya akhirnya secara manual perlu membangun biner melalui PKGBUILD, karena lebih sederhana dan dengan penyesuaian saya dapat memaksa PKGBUILD untuk menggunakan komit containerd tertentu (yang saya setel ke docker/containerd@03e5862ec0d8d3b3f750e19fca3ee367e13c090e):

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

Saya harus segera mendapatkan hasil perbaikan.

Saya mungkin melakukan sesuatu yang salah, tetapi saya tidak dapat memulai kontainer sama sekali sekarang:

Oh, saya kira saya harus memperbarui runc... brb membangun kembali

Ya, perbaikannya sepertinya tidak berhasil:

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

Kecuali Anda dapat mereproduksi ini di VM Anda sendiri, saya bersedia memberikan akses ke VM saya tempat saya mereproduksi masalah ini, dan membuat paket Docker khusus untuknya.

Saya melihat ini di buruh pelabuhan 1.12.3 di CentOs 7

dc2-elk-02:/root/staging/ls-helper$ docker --version
Docker versi 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 Sen 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
Respons kesalahan dari daemon: Driver devicemapper gagal menghapus sistem file root e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: Perangkat Sibuk

Saya tidak menggunakan komposisi buruh pelabuhan.

Saya pikir mungkin saya juga mengalami kesalahan ini.

Saya melihat banyak kesalahan ini ketika kami menjalankan tes penerimaan untuk Flocker:

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

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

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 4
Server Version: 1.12.4
Storage Driver: devicemapper
 Pool Name: docker-8:1-1072929-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 525.5 MB
 Data Space Total: 107.4 GB
 Data Space Available: 8.327 GB
 Metadata Space Used: 1.384 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.135-RHEL7 (2016-09-28)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: flocker local
 Network: host bridge overlay null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-514.2.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.305 GiB
Name: acceptance-test-richardw-axpeyhrci22pi-1
ID: 4OHX:ODXJ:R2MH:ZMRK:52B6:J4TH:PMDR:OQ5D:YUQB:5RE3:YDAQ:V5JP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

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

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

[Install]
WantedBy=multi-user.target

@rhvgoyal @rhatdan @vbatts
Mengalami masalah 'Perangkat sibuk' selama penghapusan/penghapusan kontainer yang dihentikan/mati pada RHEL7.1 yang menjalankan dockerd 1.12.4 dengan penghapusan & penghapusan yang ditangguhkan diaktifkan=true tanpa MountFlags di file unit systemd docker.service.
Juga melihat pesan kernel seperti:
"kernel: device-mapper: thin: Penghapusan thin device 120 gagal." (120 menjadi id perangkat dari perangkat thinpool wadah yang dikeluarkan)

Dalam semua kasus, titik pemasangan perangkat thinpool devicemapper untuk wadah yang dihapus bocor ke ruang nama pemasangan pid lain pada Host yang sedang dimulai dengan MountFlag=private/slave.

• ntpd.service dimulai dengan PrivateTmp=true di RHEL
• layanan systemd-udevd dimulai dengan MountFlags=slave di RHEL
  Pada host di mana penghapusan penampung gagal, salah satu dari proses ini dimulai ulang setelah waktu mulai penampung yang sesuai.

Jadi, sepertinya sangat mudah untuk membocorkan mount point di host mount namespace, karena sistem di atas memproses unshares beberapa mount namespaces, secara default, yang tidak dapat diubah/dikendalikan satu per satu.
Apakah menjalankan dockerd dengan mountflags=slave adalah satu-satunya solusi di sini? Anda juga dapat membantu saya memahami mengapa mountflags=slave (dan default untuk dibagikan) telah dihapus beberapa waktu lalu dari file unit docker systemd.
Dalam skenario apa, menjalankan dockerd dengan propagasi titik pemasangan budak merusak hal-hal lain?
Terima kasih.

Ada perbedaan dalam kernel RHEL dengan kernel upstream yang kami coba perbaiki, yang memaksa kami untuk menjalankan dockerd di namespace mount-nya sendiri, di Fedora kernel bekerja secara berbeda yang memungkinkan kami menjalankan dockerd di namespace host.

@rhvgoyal dapat memberi Anda detail berdarah.

@ravilr , pada kernel

Jalankan juga buruh pelabuhan dengan MountFlags=slave

Anda dapat terus menggunakan penghapusan yang ditangguhkan pada kernel rhel/centos dan itu akan berhasil.

BTW, jika Anda menggunakan docker-storage-setup untuk mengatur penyimpanan, itu akan secara otomatis mencari tahu apakah kernel yang mendasari mendukung penghapusan yang ditangguhkan atau tidak dan mengatur/membatalkan opsi itu.

@rhvgoyal apakah Anda tahu cara untuk mengosongkan ruang setelah gagal menghapus sistem file root wadah?

@rhvgoyal Terima kasih atas sarannya. Saya akan mencoba seperti yang Anda sarankan dan laporkan kembali ke sini, jika kami terus melihat masalah terkait seputar penghapusan penampung.

Menabrak; apakah ada info lebih lanjut yang Anda butuhkan untuk membantu menyelesaikan ini?

Saya telah mencapai ini sendiri dengan menjalankan 1.12.5 di Centos 7.

Mengaktifkan moutflags=slave serta mengaktifkan penghapusan dan penghapusan yang ditangguhkan telah memperbaiki masalah ini untuk saya. Sekarang saya menemukan bug kondisi balapan ini: https://github.com/docker/docker/issues/23418

Ini sekitar 100x lebih baik daripada harus memaksa mengeluarkan wadah yang macet, tetapi tetap tidak bagus.

Saya dapat melakukan repro pada CentOS 7 di xfs.

Masalah yang sama di sini, 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

Adakah resolusi yang terlihat untuk yang satu ini? Saya masih melihat masalahnya dan upaya saya untuk menemukan proses menahan perangkat tetap terbuka telah gagal. Sepertinya tidak ada proses yang menahan perangkat yang sibuk tetap terbuka.

Terima kasih.

(Pembaruan pada komentar saya: Tidak jelas pada pembacaan pertama utas, tetapi sepertinya mengaktifkan penghapusan yang ditangguhkan dan pengaturan MountFlags=slave dapat memperbaikinya. Saya juga akan memperbarui Docker ke 1.13.)

seseorang yang ingin memperbaiki masalah ini dapat melihat komentar @ravilr di atas, detailnya di bawah:

Dalam semua kasus, titik pemasangan perangkat thinpool devicemapper untuk wadah yang dihapus bocor ke ruang nama pemasangan pid lain pada Host yang sedang dimulai dengan MountFlag=private/slave.

ntpd.service dimulai dengan PrivateTmp=true di RHEL
layanan systemd-udevd dimulai dengan MountFlags=slave di RHEL
Pada host di mana penghapusan penampung gagal, salah satu dari proses ini dimulai ulang setelah waktu mulai penampung yang sesuai.

either of these processes were restarted after the corresponding container start time. adalah titik kuncinya, file di beberapa direktori seperti "tmp" digunakan oleh namespace lain tidak hanya wadah buruh pelabuhan, jadi buruh pelabuhan tidak dapat membunuhnya tanpa paksa.
Anda dapat memperbaiki masalah ini dengan menghentikan proses yang dimulai ulang atau mengatur parameter systemd mereka PrivateTmp=true menjadi salah dan memulai kembali.

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

@KevinTHU Mungkin saya salah paham dengan komentar Anda.

Tetapi dalam kasus saya (ubuntu 14.04), yang harus saya lakukan untuk memperbaikinya, adalah memulai kembali layanan buruh pelabuhan itu sendiri
( service docker restart ). tidak ada "ntpd.service" atau "systemd-udevd service" yang terlibat.

Apakah itu masuk akal?

@quexer tentu saja, memulai ulang buruh pelabuhan dapat menyelesaikan masalah ini, tetapi, semua wadah juga akan dimulai ulang, itu terlalu mahal untuk lingkungan produksi

@KevinTHU memulai ulang layanan buruh pelabuhan JANGAN memengaruhi wadah apa pun yang sedang berjalan. Anda bisa mencobanya sendiri.

@quexer Itu tergantung pada konfigurasi Anda. Tetapi saya menduga bahwa jika Anda membiarkan kontainer berjalan dengan mode --live-restore , itu mungkin tidak menyelesaikan masalah.
Secara default, Docker akan menghentikan semua wadah saat keluar, dan masih jika ada sesuatu ketika datang cadangan, itu akan membunuh mereka juga.

@cpuguy83 @KevinTHU Maaf, ini salahku. Anda benar, restart docker akan menyebabkan semua container restart.

Saya sekarang mendapatkan ini secara teratur dengan salah satu VM saya, tiba-tiba. Menariknya, salah satunya menjadi dapat dihapus setelah 8+ jam dibiarkan begitu saja. Berikut info saya:

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)

Dan itu rusak lagi.

Tidak tahu apakah ini relevan, tetapi /var/log/messages memiliki:

14 Februari 16:58:49 kernel vrici: dev_remove: 40 panggilan balik ditekan
14 Februari 16:58:54 kernel vrici: dev_remove: 40 panggilan balik ditekan
14 Februari 16:58:59 kernel vrici: dev_remove: 40 panggilan balik ditekan

Kesalahan saat ini adalah:

Tanggapan kesalahan dari daemon: Driver devicemapper gagal menghapus sistem file root b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e: gagal menghapus perangkat dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08bdef48189f

Perangkat sibuk di suatu tempat. Bisakah Anda mencoba mengikuti skrip setelah kegagalan dan melihat di mana perangkat mungkin sibuk.

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
Tidak ada pid yang ditemukan
rlpowell@vrici> sudo docker rm freq_build
Respons kesalahan dari daemon: Driver devicemapper gagal menghapus sistem file root b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10: gagal menghapus perangkat 5f1095868bbfe85afccf392f6f4fbb8ed4bcfac88a5a8044bb12263b7659bb1263

Oh, sepertinya itu hash yang salah.

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

Itu ... sangat aneh. Saya tidak tahu mengapa proses php-fpm yang sama sekali tidak terkait akan terlihat oleh kernel untuk menahan tunggangan itu tetap terbuka.

@rlpowell Ya, itulah seluruh masalah di balik masalah ini. Sesuatu menyebabkan mount namespace tidak berfungsi dengan baik.

Saya menemukan apa yang tampaknya berfungsi di sini: http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Ini pada dasarnya berarti menambahkan baris berikut ke file systemd docker.service Anda:
MountFlags=pribadi

Ini tampaknya berhasil, setidaknya untuk sampel kecil dari docker run yang telah saya lakukan sejak menyebarkannya. Akan lebih baik jika seseorang yang sepenuhnya memahami buruh pelabuhan dapat menjelaskan konsekuensi dari bendera ini, saya menduga bahwa sistem file yang dipasang setelah buruh pelabuhan dimulai mungkin tidak tersedia untuk wadah, tetapi sejujurnya saya tidak tahu. Konfigurasi kami untuk digunakan pada server build dan di sana tampaknya berfungsi dengan baik.

Masalah yang cukup besar ini, secara efektif membuat buruh pelabuhan tidak dapat digunakan pada Centos 7/RHEL - (dan telah dibuka selama 4 bulan?)
Ada ETA?

RHEL/centos terbaru harus dikirimkan dengan MountFlags=slave di file docker.service.

@rhvgoyal ini tidak terjadi: https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm

Ini ada di master cabang, tetapi cabang 1.13.x dan 17.03.x juga tidak memilikinya.

Sejauh yang saya tahu adalah bahwa bendera ini ada di unit layanan sebelumnya tetapi telah dihapus. Tapi saya tidak menemukan alasannya. Mungkin flag ini menyelesaikan masalah saat ini tetapi menciptakan masalah lain.

@rlpowell @SEAPUNK sepertinya ini tidak terjadi di instalasi ubuntu saya:

$ 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

Saya menulis artikel yang menjelaskan mengapa RHEL7 tidak dapat mendukung --live-restore hingga RHEL7.4 dan mengapa buruh pelabuhan harus dijalankan dalam namespace mount yang berbeda dengan Host.

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

+1 Saya ingin menjalankan dengan namespace mount yang berbeda dan menjadikan semua docker mount pribadi.
Ada beberapa bit rumit di sana, meskipun.

Jika buruh pelabuhan hulu tidak memiliki tanda yang tepat untuk berjalan di MountFlags=slave maka itu adalah bug dan akan dengan mudah memicu masalah dengan ruang nama mount yang bocor antara wadah dan Host dan dapat menyebabkan masalah dengan menghapus gambar wadah.

FWIW, MountFlags=slave telah dihapus di https://github.com/docker/docker/pull/22806 , setelah ditinjau oleh pengelola Red Hat, tetapi sepertinya itu menyebabkan masalah, jadi bertanya-tanya apakah itu harus dikembalikan sampai RHEL7.4?

Ya, kami telah menghapusnya dan kemudian menyebabkan masalah sehingga di salah satu utas diskusi kami menyimpulkan bahwa mari kita perkenalkan kembali. Saya pikir Anda sudah melakukannya. Tapi lupa itu thread yang mana.

@thaJeztah Yup kami salah dan menemukan masalah tambahan.

Dan masalah ini terutama khusus untuk kernel yang lebih tua. Kernel yang lebih baru berfungsi dengan baik.

Biarkan saya membuka PR untuk mendiskusikan opsi

PR dibuka di sini; https://github.com/docker/docker/pull/31490

masalah yang sama buruh pelabuhan 1.10.3 CentOS Linux rilis 7.2.1511
dmesg：
[1732917.246900] device-mapper: ioctl: tidak dapat menghapus open device docker-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78
pesan
3 Apr 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346374677+08:00" level=error msg="Kesalahan menghapus lapisan terpasang b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c13f216517a "
3 Apr 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346597095+08:00" level=error msg="Handler for DELETE /v1.22/containers /b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2d mengembalikan kesalahan: Driver devicemapper gagal menghapus sistem file root b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517d:

Gunung:
temukan /proc/*/mounts | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
/ Proc / 159.779 / tunggangan: / dev / mapper / buruh pelabuhan-8: 3-5.242.884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / ekspor / buruh pelabuhan / devicemapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 xfs rw, relatime, nouuid, attr2, inode64, logbsize = 64k, sunit = 128, lebar=128,nokuota 0 0
/ Proc / 159.806 / tunggangan: / dev / mapper / buruh pelabuhan-8: 3-5.242.884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / ekspor / buruh pelabuhan / devicemapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 xfs rw, relatime, nouuid, attr2, inode64, logbsize = 64k, sunit = 128, lebar=128,nokuota 0 0
wadah baru
buruh pelabuhan memeriksa 8777d36c94ec|grep Pid
"Pid": 159779,

//salahku，telah menyelesaikannya

Apa itu ID "8777d36c94ec"? Ini adalah ID wadah wadah yang sedang dihapus atau wadah lain?

Jadi perangkat sibuk karena masih terpasang di wadah. Jadi salah satu wadah yang dikeluarkan belum berhenti. Atau jika wadahnya berbeda, maka seharusnya tidak terlihat di wadah lain.

Tidak yakin apa titik mount "/export/docker/devicemapper/mnt/...." dan siapa yang membuat ini?

Pada sistem Mint saya, memutakhirkan dari 17.03.1~ce-0~ubuntu-xenial ke 17.04.0~ce-0~ubuntu-xenial menyebabkan masalah ini sering terjadi.

Sebelum upgrade, saya belum pernah menemuinya. Setelah upgrade sangat sering. Menurunkan kembali ke 17.03.1 tampaknya telah menyelesaikannya.

Sebagai catatan untuk orang lain yang membaca utas ini, jika Anda menjalankan cAdvisor dari Google, Anda akan melihat masalah ini saat mencoba menghapus penampung. Pertama, Anda harus menghentikan cAdvisor, lalu menghapus wadahnya, lalu memulai lagi cAdvisor.

@bmbroom Ditto. Kami menjalankan server build berdasarkan ubuntu yang melakukan churn container sepanjang hari (biasanya didorong oleh docker-compose), dan kami telah melihat masalah ini beberapa kali seminggu. Server adalah campuran tepercaya dan xenial. Kami baru-baru ini mulai meningkatkan ke 17.04.0~ce dan melihat ini terjadi beberapa kali sehari sekarang.

Saya tidak jelas apakah MountFlags=slave berlaku untuk ubuntu, tapi itulah yang saya coba selanjutnya.

@rhvgoyal
maaf，salahku。
yang lain masih terpasang di wadah saya。

Baru saja mengalami masalah yang sama pada:

• buruh pelabuhan: Docker versi 17.03.1-ce, build c6d412e
• os: Red Hat Enterprise Linux Server rilis 7.3 (Maipo)
• kernel: 3.10.0-514.6.1.el7.x86_64
• ntpd: 4.2.6p5

Melakukan systemctl restart ntpd memperbaiki masalah secara instan.

@xeor
apa MountFlags di dalam file unit docker.service Anda?

Tidak ada MountFlags dalam file /usr/lib/systemd/system/docker.service , tetapi systemctl show docker menunjukkan MountFlags=0 .

Hal yang sama untuk ntpd.service . Itu juga memiliki PrivateTmp=true bawah bait [Service] (jika itu penting).

Jalankan dengan MountFlags=slave untuk saat ini.

@rhvgoyal memeriksa file docker.service saya. Tetapi nilai Anda sudah ditetapkan:

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

menggunakan redhat terbaru(3.10.0-514.16.1.el7)/docker(1.12.6-16.el7)

bagaimana dengan MountFlags=private ? Bisakah Anda menjelaskan perbedaan antara pribadi dan budak?

Saat ini saya melihat masalah ini pada RHEL/CentOS 7.3, kernel 3.10.0-514.16.1.el7.x86_64, dengan versi Docker 17.05.0-ce, build 89658be. Kami telah melihat masalah ini terus menerus selama setahun terakhir.

Kami juga tidak memiliki opsi MountFlags di /etc/systemd/system/multi-user.target.wants/docker.service. Haruskah kita menambahkan "MountFlags=slave" di sana?

Saya melihat komentar yang mengatakan masalah ini terjadi di Centos, RHEL, dan Ubuntu. Apakah sistem operasi lain aman dari masalah khusus ini, seperti Debian atau ContainerLinux atau SUSE?

@earwax Apa pun dengan kernel yang lebih baru (>= 3.15) umumnya akan bekerja lebih baik.
Tetapi selalu ada situasi yang dapat Anda buat di mana kesalahan ini terjadi.
Juga, ada beberapa cara yang tercantum dalam komentar di sini untuk menguranginya.

Saya melihat masalah ini di SUSE...tetapi tidak dapat menemukan solusi untuk itu...Saya melihat ini sebagian besar terjadi pada penyedia: AZURE

kami juga menemukan masalah ini, ketika kami memperbarui dockerd dari 1.12.6 ke 17.05. Semua container lama tidak dapat dihapus tanpa '-f', container ini memiliki fitur umum bahwa semuanya tidak dihentikan saat kami memperbarui dockerd, karena kami memiliki konfigurasi '--live-restore'. Saya pikir ada beberapa masalah di sini.

Ini masih menjadi masalah di 17.06, FYI, setidaknya dengan CentOS 7.

@ MGD1981 bug ini perlu diperbaiki, kami menggunakan centos 7 yang sama, dan kami menemukan bahwa tidak hanya wadah lama yang dibuat sebelum memperbarui buruh pelabuhan memiliki masalah "perangkat sedang sibuk", tetapi juga wadah yang baru dibuat, ini sangat penting , dan kami mengatasinya dengan menambahkan "MountFlags=slave" ke docker.service. Namun, kami tidak tahu apakah parameter ini akan membawa masalah lain.

Ya, coba ini sekarang di lingkungan QA kami. Akan memperhatikan dengan seksama
ke gunung. Apakah ada potensi risiko FS kontainer menjadi
"terlupakan" tentang pengaturan ini, seiring waktu mengisi host dengan disk
kontainer mati?

Pada Senin, 3 Juli 2017, 22:38 KevinTHU [email protected] menulis:

@MGD1981 https://github.com/mgd1981 bug ini perlu diperbaiki, kami
menggunakan centos 7 sama, dan kami menemukan bahwa tidak hanya wadah lama
dibuat sebelum memperbarui buruh pelabuhan memiliki masalah "perangkat sibuk", tetapi juga
wadah baru yang dibuat, ini sangat penting, dan kami mengatasinya dengan
menambahkan "MountFlags=slave" ke docker.service. Namun, kami tidak tahu cuaca
parameter ini akan membawa beberapa masalah lain.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/27381#issuecomment-312766596 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.

@ MGD1981 ya, sepertinya ada disk di Host yang tidak digunakan lagi. Lihat #33025

@ceecko Ini seharusnya tidak terjadi lagi pada 17.06, meskipun jika Anda mengaktifkan penghapusan/penghapusan yang ditangguhkan, maka itu mungkin tidak segera dibersihkan.

@cpuguy83 bagus! Apakah ini akan membersihkan disk lama yang ditinggalkan oleh versi sebelumnya juga?

@cpuguy83 adalah 17,06 dirilis belum? (ini sudah bulan Juli, jadi 17.07?) tidak ditemukan di halaman rilis github.

@ravilr Sudah keluar. Rilis berasal dari github.com/docker/docker-ce.

@ceecko saya rasa tidak.

@cpuguy83 terima kasih. catatan rilis untuk 17.06 tampaknya tidak menyebutkan perbaikan pr apa pun terkait masalah ini. apa perbaikan untuk mengatasi ini? Terima kasih lagi.

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

Saya menjalankan 17.06.0-ce pada CentOS 7 (dengan penyimpanan kumpulan tipis) dan ini sering terjadi belakangan ini.

+ 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

Apakah itu dengan atau tanpa MountFlags=slave , @AaronDMarasco-VSI ? CentOS 7.3?

17.06 tidak memperbaiki masalah mendasar, hanya lebih baik dalam menanganinya.
Saya melihat apakah ada sesuatu yang dilakukan buruh pelabuhan (atau sub-komponen seperti containerd) yang memperburuk masalah.

@esabol Tidak... pribadi?

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) 

Nah, @AaronDMarasco-VSI, saya sarankan untuk mengubahnya menjadi MountFlags=slave , yang telah meningkatkan situasi bagi kami, tetapi kami masih menggunakan 17,05 dan saya pikir saya melihat suatu tempat yang tidak ingin Anda gunakan MountFlags=slave dengan dm.use_deferred_removal ? Mungkin orang lain akan berkomentar dan mengkonfirmasi.

Saya menggunakan buruh pelabuhan 17.03 pada centos 7.3 dan kernel 4.10. dan saya telah melihat banyak kesalahan ini. di bawah ini adalah beberapa detail lebih lanjut tentang MountFlag.

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

masalah yang sama di sini dengan Debian 8. itu merusak CI kami, adakah cara yang mungkin dilakukan??

@thg303 coba matikan dockerdeamon Anda, jika memungkinkan dan coba bersihkan/hapus sistem file root yang terjadi di file log Anda (rm /var/lib/docker/..... ). Tetapi Anda harus mengambil snapshot/cadangan sebelum :-)

Masalah yang sama di sini dengan 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.

Saya mengalami masalah ini setiap kali buruh pelabuhan diperbarui pada centos7. Saya me-restart buruh pelabuhan dan kemudian semuanya berfungsi dengan baik.

Sama untuk saya di Fedora 26 dengan Docker 17.06.0-ce. Restart buruh pelabuhan tidak memperbaiki masalah.

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

Serius datang pada satu tahun sekarang dan bug ini masih ada di sini?

@NeckBeardPrince Tolong jangan buang waktu kami dengan komentar yang tidak berguna.
Jika Anda ingin membantu menyelesaikannya, bagus. Jika Anda ingin melaporkan lebih banyak data tentang masalah tersebut, bagus.

Selain itu, ada beberapa cara untuk mengatasi masalah ini yang telah diposting di sini.

file unit systemd tidak dikirimkan dengan 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

Terakhir kali saya mengalami masalah ini, ntpd yang menahan tunggangan.
Hari ini, saya mendapat masalah yang sama, dan kali ini, itu adalah instance mariadb berjalan di Host itulah alasannya.

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

Contoh untuk menemukan proc yang memegang tunggangan ....

# 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

Setelah memulai ulang mariadb, ia melepaskan mountpoints, namun, ia mengambil banyak dari mereka ketika dimulai.

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

Sebagian besar kegagalan penghapusan disebabkan oleh titik pemasangan (karenanya device ) sedang sibuk di beberapa ruang nama pemasangan lainnya. Saya pikir mengikuti PR yang diusulkan akan membantu masalah ini jika kernel cukup baru.

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

Jika Anda menjalankan kernel lama, maka kami telah menulis panggilan plug-in oci-umount untuk mengurangi masalah kebocoran pemasangan.

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

@rhvgoyal Apakah Anda punya rencana rilis docker mana yang akan menyertakan PR ini? Kami masih berurusan dengan driver "devicemapper" failed to remove root filesystem secara teratur.

CentOS Linux rilis 7.4.1708 (Inti)
3.10.0-693.5.2.el7.x86_64
17.06.2-ce

TERLIHAT SEPERTI AKHIRNYA DIPERBAIKI

Kami menjalankan Docker versi 17.09.0-ce dan masih menghadapi masalah yang sama.

Kami terkadang mengalami masalah ini di Oracle Linux :, dengan versi buruh pelabuhan 17.03.1-ce (Dari repo Oracle)

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

Semua hal di atas telah diperbaiki oleh TDA proyek, jadi kami tidak dapat mengubahnya untuk saat ini.

90% dari lingkungan kami yang lain adalah Centos 7.3/7.4, dan kami belum melihat masalah di sana.

Baru saja berhasil memecahkan contoh masalah ini dengan Docker 17.05 di arch Linux pada 4.11.9
oleh

1. docker rm -f [myContainer] (gagal dengan driver "devicemapper" failed to remove root filesystem seperti biasa)
2. ls /var/lib/docker/devicemapper/mnt/

Ini membuat wadah akhirnya menghilang (meskipun tidak yakin mengapa).

@MonsieurWave luar biasa seperti yang terlihat, trik "ls" bekerja dengan sempurna untuk saya ketika yang lainnya tidak!

docker rm -f [container] akan melaporkan kegagalan tetapi pada akhirnya membersihkan wadah dan sistem file. Perintah ls adalah red herring, yang Anda perlukan hanyalah menunggu beberapa detik. Tetapi lebih baik dari itu adalah menggunakan MountFlags=slave . Dan yang terbaik adalah mematikan devicemapper dan menggunakan overlay2 sebagai gantinya.

Dan yang terbaik adalah mematikan devicemapper dan menggunakan overlay2 sebagai gantinya.

Kami telah menggunakan Docker di CentOS 7.x (saat ini di 7.4) selama lebih dari satu tahun sekarang. Ketika kami pertama kali menginstal Docker, semuanya dan semua orang mengatakan Anda harus menggunakan devicemapper dengan direct-lvm untuk kinerja dan stabilitas terbaik. https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ masih mengatakan Anda harus menggunakan devicemapper di CentOS dengan Docker EE. Untungnya, kami menggunakan Docker CE, sehingga kami dapat beralih ke overlay2. Saya merasa seperti orang-orang Docker tergelincir dalam perubahan default dari devicemapper ke overlay2 pada CentOS di v1.13.0/1 dengan sedikit keriuhan atau diskusi. Apakah ada informasi yang solid tentang kinerja/stabilitas overlay2 versus devicemapper (direct-lvm) pada CentOS 7? googling saya belum banyak nemu....

Kami memiliki waktu yang sangat buruk dengan kernel CentOS 7.2 (frankenstein 3.10.x mereka). Banyak crash. Kami menjalankan Kubernetes di dev env, jadi churn container kami sangat tinggi, tetapi bahkan dalam instalasi yang relatif tenang, kami menemukan stok CentOS+overlay combo sangat tidak stabil. Menjalankan kernel upstream 4.10+ dengan overlay2 jauh lebih baik. Belum mencoba rilis CentOS yang lebih baru.

Anda harus menggunakan sistem file yang mendasarinya yaitu ext4 atau XFS yang diformat dengan "-n ftype=1". Docker akan berjalan jika Anda memiliki XFS yang tidak diformat dengan benar, tetapi hasilnya tidak dapat diprediksi.

Ya, saya sudah lama beralih ke overlay2, dan merekomendasikan siapa saja yang masih menggunakan devicemapper yang dapat menggunakan overlay2 untuk beralih , karena bahkan masalah ini, saya telah membaca bahwa devicemapper adalah driver penyimpanan yang sangat buruk untuk buruh pelabuhan secara umum.

Restart ntpd memperbaiki masalah yang saya alami ... sangat membingungkan. Apakah ada konfigurasi daemon.json "disarankan" untuk buruh pelabuhan di Centos7?

Beberapa perbaikan sedang dilakukan.

Secara khusus masalah dengan layanan sistem lain ini tampaknya merupakan kondisi balapan dengan menyiapkan ruang nama mount (untuk layanan sistem lain itu) dan upaya buruh pelabuhan untuk menjaga tunggangannya sendiri tetap pribadi ... wadah, sayangnya itu menyebabkan kebocoran di tempat lain dan benar-benar berakhir dengan menyimpan referensi pribadi ke titik mount tersebut yang berarti mereka tidak dapat dilepas di ruang nama tersebut kecuali secara manual atau ketika proses dimulai ulang.

Selain itu, ada beberapa perubahan terbaru untuk menangani kondisi balapan dengan menggunakan propagasi pemasangan MS_PRIVATE di runc dan buruh pelabuhan.
Apakah versi berikutnya akan sempurna? Mungkin tidak... tapi saya berharap ini menjadi lebih baik.

Saya mendapatkan hal yang persis sama dengan @ceecko dengan docker 12.1.1 , tidak ada kesempatan untuk memperbarui sekarang. Apakah itu diperbaiki nanti di suatu tempat? Perbaikan cepat adalah mematikan proses dan memulai kembali layanan buruh pelabuhan, tapi ..

Versi ini sepenuhnya memperbaiki masalah bagi saya, termasuk --live-restore

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

@esabol kami telah mengevaluasi peralihan ke overlay2 setelah kami memutakhirkan ke CentOS 7.4. Sayangnya itu terlalu banyak pekerjaan. Partisi yang bisa kita gunakan untuk menyimpan data adalah XFS dan sebelum 7.4, opsi pemformatan XFS default CentOS melewatkan satu parameter (saya lupa yang mana) untuk dapat mendukung overlay2 di atas. Jadi itu berarti kita harus memformat ulang partisi agar dapat menggunakan overlay2 di atas XFS. Saat itulah peralihan ke overlay2 akan menghabiskan terlalu banyak pekerjaan untuk menghindari waktu henti, dan kernel 7.4 terbaru + Docker 17.09 dan rekomendasi di atas untuk konfigurasi LVM banyak membantu menghindari masalah hampir sepanjang waktu.

Catatan: docker info menunjukkan peringatan besar bahwa menjalankan overlay2 melalui XFS tanpa opsi khusus ini tidak didukung dan akan dihapus di rilis mendatang.

https://github.com/moby/moby/pull/34573 perbaikan dirilis pada versi 17.09.1-ce, 17.12.0-ce

@jcberthon Kami baru-baru ini menggigit peluru dan membuat transisi ke overlay2, dan saya sangat senang kami melakukannya! Performa meningkat 40% dalam tolok ukur pengujian unit kami yang melakukan docker run --rm . Jerami terakhir bagi kami untuk devmapper adalah masalah #20401. Beralih ke overlay2 tidak terlalu sulit, tetapi kami memiliki banyak ruang disk kosong. Saya menulis skrip ke docker save semua gambar kami ke tarball dan skrip lain ke docker load semua tarball. Kami selesai dalam 2-3 jam. Saya tahu ini sepertinya merepotkan dan bisa jadi jika Anda tidak memiliki cukup ruang disk, tetapi itu akan bermanfaat dalam jangka panjang, saya pikir. Semoga beruntung!

Ini diperbaiki di 17.12.1

Terima kasih semuanya.

sebelum rilis tetap, me-reboot node fisik akan menyelesaikan masalah

@ravilr @KevinTHU mengenai komentar Anda https://github.com/moby/moby/issues/27381#issuecomment -277148106 dan https://github.com/moby/moby/issues/27381#issuecomment -267547259 Saya telah mengamati bahwa mengubah file unit buruh pelabuhan di RHEL menjadi PrivateTmp=true memperbaiki masalah juga. Adakah kemungkinan Anda pernah melihat sesuatu yang serupa?

@MohdAhmad belum pernah mencobanya, tapi saya pikir ini mungkin ok, karena PrivateTmp=true di file unit buruh pelabuhan hanya untuk buruh pelabuhan, mungkin memperbaiki masalah ini lebih baik lagi.

Saya menemukan masalah yang sama. Karena saya membuka folder, menutup jendela untuk menyelesaikannya.