Moby: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر. الجهاز مشغول

هل هذا يحدث مع أي حاوية؟ ما الذي يعمل في الحاوية ، وما الخيارات التي تستخدمها لبدء تشغيل الحاوية؟ (على سبيل المثال ، هل تستخدم أدلة مثبتة ، هل تستخدم docker exec لبدء عمليات إضافية في الحاوية؟)

نقوم بتشغيل جميع الحاويات بنفس الطريقة تقريبًا ويحدث ذلك بشكل عشوائي على أي منها.
نحن لا نستخدم docker exec ، لا تقم بتثبيت أي أدلة.
إليك تكوين إحدى الحاويات الميتة:

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

لقد لاحظت للتو أن هذا يحدث فقط على الخوادم مع نظام الملفات هذا Backing Filesystem: ext4
لا يبدو أن المشكلة تحدث على الخوادم التي تستخدم xfs كنظام ملفات احتياطي.

ceecko شكرا ، هذا مثير للاهتمام

rhvgoyal هل هذه مشكلة معروفة من جانبك؟

هذا يضربنا بشدة في الإنتاج: / هل من تلميحات عن كيفية إزالة الحاويات الميتة؟

thaJeztah الغريب أن هذا سيحدث فقط مع ext4 وليس xfs. أنا لست على علم بأي شيء من هذا القبيل.

بشكل عام ، أبلغ الأشخاص عن أن الجهاز مشغول ويمكن أن يكون هناك العديد من الأسباب لذلك.

ceeko أولاً تأكد من أن Docker daemon يعمل في مساحة اسم جبل تابعة خاصة به وليس مساحة اسم جبل المضيف. بحيث لا تتسرب نقاط التحميل وتكون فرص حدوث مثل هذه الأخطاء أقل. إذا كنت تستخدم عامل إرساء مدفوعة بواسطة systemd ، فيجب أن يكون هناك ملف وحدة عامل إرساء ويجب أن يحتوي على MountFlags = slave.

rhvgoyal يبدو أن MountFlags=slave يحل المشكلة حتى الآن. لا تزال الحاويات التي تم إنشاؤها قبل التغيير تمثل مشكلة ولكن لا يبدو أن الحاويات الجديدة تؤدي إلى حدوث الخطأ حتى الآن. سأتواصل معك في حال تغير أي شيء.

راجع للشغل قد يكون من المفيد تحديث مستندات برنامج تشغيل التخزين للتوصية بهذا كأفضل ممارسة في الإنتاج حيث لم أتمكن من العثور على أي مرجع.

شكرا لك على مساعدتك.

تم تغيير هذا منذ فترة. https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68 (https://github.com/docker/docker/pull/22806) ، قد تكون هذه إزالة إذا تم تأجيلها غير مفعل؛ https://github.com/docker/docker/pull/22806#issuecomment -220043409

يجب علينا تغيير الافتراضي مرة أخرى؟ تضمين التغريدة

thaJeztah أعتقد أنه قد يكون من الجيد تغيير الوضع الافتراضي مرة أخرى إلى MountFlags = slave. لقد فعلنا ذلك.

من المفترض أن تهتم ميزات الإزالة المؤجلة والحذف المؤجل بهذا الأمر ولم تكن هناك حاجة لاستخدام MountFlags = slave. لكن تأجيل الحذف وحده لا يكفي. تفتقر النوى القديمة إلى ميزة يمكن من خلالها إزالة دليل من مساحة اسم التحميل حتى لو تم تثبيتها في مساحة اسم تحميل مختلفة. وهذا أحد أسباب فشل إزالة الحاوية.

لذا ، حتى تقدم النوى القديمة هذه الميزة ، قد يكون من الجيد تشغيل برنامج Docker daemon في مساحة اسم slave mount.

rhvgoyal بدأت الأخطاء بالظهور مرة أخرى حتى مع MountFlags=slave . سنحاول الإزالة المؤجلة والحذف وسنعاود الاتصال بك.

لقد واجهنا نفس الخطأ في xfs أيضًا.
ها هي معلومات عامل الميناء

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

أؤكد أن الخطأ لا يزال يحدث في 1.12.2 حتى مع MountFlags=slave و dm.use_deferred_deletion=true و dm.use_deferred_removal=true على الرغم من أن تكرار هذا الخطأ أقل من ذي قبل.

إليك مزيد من المعلومات من السجلات المتعلقة بحاوية واحدة لا يمكن إزالتها:

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

تشير الرسالة التالية إلى فشل إزالة الدليل.

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

وفي النواة الأقدم يمكن أن يفشل لأنه تم تحميل الدليل في مساحة اسم تحميل أخرى. إذا عطلت ميزة deferred deletion ، فسيتوقف ظهور هذه الرسالة. لكنها ستصبح رسالة خطأ أخرى.

يتمثل جوهر المشكلة هنا في أن الحاوية إما لا تزال قيد التشغيل أو أن بعض نقاط التحميل الخاصة بها قد تسربت إلى مساحة اسم تحميل أخرى. وإذا تمكنا من معرفة مساحة اسم التحميل التي تسربت إليها وكيف وصلت إلى هناك ، فيمكننا محاولة إصلاحها.

بمجرد مواجهة هذه المشكلة ، يمكنك محاولة القيام بـ find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543"

ثم انظر إلى أي لوحات تحتوي على حوامل متعلقة بالحاويات المتسربة إليها. وهذا قد يعطي فكرة.

لقد جربت أربع حاويات ماتت جميعها ولا يمكن إزالتها بسبب انشغال الجهاز ولم أحصل على شيء: /

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

أتلقى الآن رسالة خطأ مختلفة قليلاً:

# 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

نفس الشيء. لا يمكن حذف هذا الدليل لأنه مثبت عليه في مساحة اسم تحميل أخرى. حاول البحث في / proc // mounts و grep لهذا المعرّف 527ae5 وتعرّف على pid الذي يرى نقطة التحميل هذه. نحتاج إلى معرفة أنه في الإعداد الخاص بك سبب تسرب نقطة تحميل rootfs للحاوية إلى مساحة اسم التحميل الأخرى.

ها نحن ذا:

# 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

ما هي عمليات تعيين هذه pids؟ جرب cat /proc/<pid>/comm أو ps -eaf | grep <pid>

هذه كلها عمليات عامل nginx يتم إيقافها بعد إعادة تحميل التكوين (انظر التعليق المعدّل أعلاه). أتساءل لماذا يمنعون الحوامل لأن الحاويات لا تربط أي أحجام.

إذن عملية nginx تعمل في حاوية أخرى؟ أم أنها تعمل على المضيف؟

هل يمكنك أن تفعل ما يلي.

• ls -l /proc/<docker-daemon-pid>/ns/mnt
• ls -l /proc/<nginx-pid>/ns/mnt
• قم بتشغيل bash shell على المضيف وتشغيل ls -l /proc/$$/ns/mnt

ولصق الإخراج. هنا.

يعمل nginx على المضيف.

عامل ميناء

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

يبدو أن كل من docker-pid والمضيف يشتركان في نفس مساحة اسم التحميل. وهذا يعني أن Docker daemon يعمل في مساحة اسم جبل المضيف. وهذا يعني على الأرجح أن nginx بدأ في مرحلة ما بعد بدء الحاوية ويبدو أنه يعمل في مساحة اسم التحميل الخاصة به. وفي ذلك الوقت ، تسربت نقاط التحميل إلى مساحة اسم nginx mount وهذا يمنع حذف الحاوية.

يرجى التأكد من أن MountFlags = slave يعمل من أجلك. بمجرد أن يعمل ، / proc /سيعطي / ns / mnt إخراجًا مختلفًا لبرنامج docker daemon و bash shell الذي يعمل في مساحة اسم تحميل المضيف.

أنت على حق. لم يتم إعداد MountFlags=slave لهذا المضيف حتى الآن.
لكن مضيف آخر فعل ذلك ولا يزال هناك حاويات ميتة. لقد قمت بإزالتها جميعًا يدويًا الآن ، ولكن تم إنشاؤها باستخدام MountFlags=slave .

سأنتظر حتى يتكرر الموقف وسأنشر تحديثًا هنا. شكرا.

الوضع الآن كما يلي - نستخدم MountFlags=slave والإزالة المؤجلة والحذف وأحيانًا تلقي واجهة برمجة التطبيقات البعيدة خطأً يفيد بأن الجهاز مشغول ولا يمكن إزالته. ومع ذلك ، عندما يتم استدعاء docker rm container مباشرة بعد الخطأ ، فإنه يزيل الحاوية على ما يرام.

ظهرت القضية مرة أخرى.

دوكيرد

# 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

العمليات من الأمر السابق

  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

حسنًا ، يرى عامل ميناء الحاويات هذا نقطة التثبيت ، وبالتالي يبقيها مشغولة. لست متأكدًا مما هو docker-containerd-shim ولماذا تتسرب نقطة التثبيت هناك. من يعرف عنها.

crosbymichael قد تعرف عنها.

cc mrunalp

شكرا على ping. سألقي نظرة.

ceecko هل يمكنك التحقق من مساحة اسم التحميل الخاصة

rhvgoyal يشتركان في نفس مساحة الاسم

دوكيرد

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

راجعت ثلاث عمليات لرسو السفن والحاويات

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

ليس لدينا أي حاويات ميتة لا يمكن إزالتها الآن.
الشيء هو أننا مرتين في الأسبوع نتوقف بانتظام ونزيل جميع الحاويات ونبدأ في إنشاء حاويات جديدة بنفس التكوين. قبل هذا "إعادة التشغيل" ينتهي الأمر ببعض الحاويات ميتة ولا يمكن إزالتها. بعد "إعادة التشغيل" العادية ، ينتهي الأمر بمعظم الحاويات ميتة ، ولكن عندما يتم إيقاف جميع الحاويات القديمة ، يمكن إزالة جميع الحاويات الميتة فجأة.

لدي نفس المشكلة ، ولكني أحصل أيضًا على بعض الأخطاء الإضافية عندما أحاول إعادة إنشاء حاوية باستخدام 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"

على وجه الخصوص ، الخطأ Error closing logger: invalid argument ، بالإضافة إلى الخطأ failed to exit within 10 seconds ، والذي أنا متأكد من أنه لا يجب أن يحدث لأنني أستخدم البادئة لبدء

هل هذه الأخطاء متعلقة بهذه المشكلة؟

أنا أعمل حاليًا على إصلاح هذا. لدي علاقات عامة مفتوحة في الحاوية للمساعدة.

من الصعب العثور على طريقة قابلة للتكرار لاختبار ذلك ، فبعد الانتهاء من الإصلاح ، هل سيكون أحدكم مهتمًا باختبار هذا الإصلاح؟

نعم بالتأكيد. سأحاول إنشاء آلة افتراضية يمكنني من خلالها إعادة إنتاج هذه المشكلة ، ومحاولة الإصلاح هناك ؛ إذا لم يفلح ذلك ، فسأختبره على الخادم الذي أواجه فيه المشكلات.

لقد قمت بإنشاء VM الآن وتمكنت (بسهولة تامة!) من إعادة إظهار المشكلة.

هذا ما فعلته مع Virtualbox:

1. قم بتثبيت نظام Arch Linux VM العادي (باستخدام عملية التثبيت العادية)
2. قم بتثبيت docker و docker-compose وخفي آخر يمكنني تشغيل عدة عمليات (في هذه الحالة ، اخترت nginx) ، ثم systemctl enable docker ، وأعد تشغيل النظام
3. قم بتكوين nginx للتشغيل مع 500 عملية عاملة
4. قم بإنشاء ملف docker-compose مع 3 حاويات تعمل لفترة طويلة (اخترت postgres ، العلامة 9.2)
5. docker-compose up -d
6. systemctl start nginx
7. قم بتغيير إصدارات اثنين من الحاويات داخل ملف إنشاء عامل الإرساء لاستخدام علامة الصورة 9.3
8. docker-compose pull
9. docker-compose up -d (يحاول إعادة إنشاء الحاويات ، ثم يعطيني خطأ "الجهاز مشغول" لكلتا الحاويات.

يتيح لي إيقاف nginx إزالة الحاويات.

docker-compose.yml اعتبارًا من الآن (لقد قلدت إعداد Docker في نظامي الفاشل):

يمكنني توفير الوصول إلى VM عند الطلب ، فقط أعطني بريدًا إلكترونيًا لإرسال تسجيل الدخول إلى.

mlaventure هل يمكن إعادة فتح هذا الإصدار؟ في الوقت الحالي ، لا نعرف ما إذا كان قد تم إصلاح هذه المشكلة أم لا.

SEAPUNK سنقوم بتحديث containerd بهذا الإصلاح المقترح. إذا كانت لديك فرصة للاختبار ، فيمكنني تزويدك بثنائيات لتجربتها.

بالتأكيد ، لدي جهاز VM الخاص بي في وضع الاستعداد.

أي فكرة متى ستكون الثنائيات جاهزة؟

المرشحين لإصدار SEAPUNK لـ 1.13 متاحون للاختبار الآن ، ويجب إجراء هذا التغيير ؛ https://github.com/docker/docker/releases

حسنًا ، سأحاول ذلك ؛ شكرا!

انا للجميع
أعتقد أنني أواجه نفس المشكلة التي يتم الإبلاغ عنها هنا

[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

انتهى بي الأمر إلى احتياج يدويًا إلى إنشاء الثنائي عبر PKGBUILD ، نظرًا لأنه أبسط ومع التعديلات يمكنني إجبار PKGBUILD على استخدام التزام حاوي معين (الذي قمت بتعيينه على docker / containerd @ 03e5862ec0d8d3b3f750e19fca3ee367e13c090e):

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

يجب أن أحصل على نتائج الإصلاح قريبًا.

قد أفعل شيئًا خاطئًا ، لكن لا يمكنني بدء تشغيل الحاويات على الإطلاق الآن:

أوه ، أعتقد أنه يجب علي تحديث runc ... إعادة بناء brb

نعم ، يبدو أن الإصلاح لا يعمل:

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

ما لم تتمكن من إعادة إنتاج هذا في جهاز VM الخاص بك ، فأنا على استعداد لتوفير الوصول إلى جهاز VM الخاص بي حيث أقوم بإعادة إنتاج هذه المشكلة ، وقمت ببناء حزمة Docker المخصصة لـ.

أرى هذا في Docker 1.12.3 على CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
إصدار Docker 1.12.3 ، النسخة 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 Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
استجابة الخطأ من البرنامج الخفي: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: الجهاز مشغول

أنا لا أستخدم عامل إنشاء السفن.

أعتقد أنه ربما أواجه هذا الخطأ أيضًا.

أرى الكثير من هذه الأخطاء عندما نجري اختبارات القبول لـ 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

rhvgoyalrhatdanvbatts
تشغيل مشكلات "الجهاز مشغول" أثناء الحذف / الحذف المتوقف / الحاوية الميتة على RHEL7.1 قيد التشغيل 1.12.4 مع تمكين الحذف والإزالة المؤجل = صحيح بدون أي MountFlags في ملفات وحدة docker.service systemd.
مشاهدة رسائل kernel أيضًا مثل:
"kernel: device-mapper: thin: فشل حذف الجهاز الرفيع 120." (120 هو معرف الجهاز لجهاز Thinpool الخاص بإزالة الحاوية)

في جميع الحالات ، تم تسريب نقطة تحميل الجهاز Thinpool للجهاز الخاص بالحاوية التي يتم إزالتها إلى مساحة اسم التحميل لمعرف بيانات آخر على المضيف الذي يتم بدء تشغيله بـ MountFlag = خاص / تابع.

• بدأ ntpd.service بـ PrivateTmp = صحيح في RHEL
• بدأت خدمة systemd-udevd بـ MountFlags = slave في RHEL
  على الأجهزة المضيفة حيث تفشل عمليات حذف الحاويات ، تمت إعادة تشغيل أي من هاتين العمليتين بعد وقت بدء الحاوية المقابل.

لذلك ، يبدو أنه من السهل جدًا تسريب نقاط التحميل في مساحة اسم تحميل المضيف ، حيث يقوم النظام أعلاه بإلغاء مشاركة بعض مساحات أسماء التحميل ، افتراضيًا ، والتي لا يمكن تغييرها / التحكم فيها بشكل فردي.
هل تشغيل dockerd مع mountflags = slave هو الحل الوحيد هنا؟ يمكنك أيضًا مساعدتي في فهم سبب إزالة mountflags = slave (والتخلف عن المشاركة) لبعض الوقت من ملف وحدة docker systemd.
تحت أي سيناريوهات ، تشغيل dockerd مع انتشار نقطة جبل الرقيق يكسر أشياء أخرى؟
شكرا.

هناك اختلافات في نواة RHEL ثم نواة المنبع التي نحاول معالجتها ، والتي تجبرنا على تشغيل dockerd في مساحة اسم التحميل الخاصة بها ، في Fedora تعمل النواة بشكل مختلف مما يسمح لنا بتشغيل dockerd في مساحة اسم المضيف.

rhvgoyal يمكنه أن يعطيك تفاصيل

ravilr ، على نواة rhel / centos ، تعطيل الحذف المؤجل. لا تحتوي Kernel على تصحيحات لدعمها.

قم أيضًا بتشغيل عامل ميناء مع MountFlags = slave

يمكنك الاستمرار في استخدام الإزالة المؤجلة على نواة rhel / centos ويجب أن يعمل ذلك.

راجع للشغل ، إذا كنت تستخدم docker-storage-setup لإعداد التخزين ، فسوف يكتشف تلقائيًا ما إذا كانت النواة الأساسية تدعم الحذف المؤجل أم لا وتعيين / إلغاء تعيين هذا الخيار وفقًا لذلك.

rhvgoyal هل تعرف أي طريقة لتحرير مساحة بعد الإزالة الفاشلة لنظام ملفات جذر الحاوية؟

rhvgoyal شكرا على الاقتراحات. سأحاول كما اقترحت وأبلغ هنا مرة أخرى ، إذا واصلنا رؤية المشكلات ذات الصلة حول إزالة الحاوية.

صدم؛ هل هناك المزيد من المعلومات التي تحتاجها للمساعدة في حل هذا؟

لقد قمت بتشغيل هذا بنفسي بتشغيل 1.12.5 على Centos 7.

أدى تمكين moutflags = slave بالإضافة إلى تمكين الإزالة المؤجلة والحذف إلى إصلاح هذه المشكلة بالنسبة لي. أنا الآن أصاب خطأ حالة السباق هذا: https://github.com/docker/docker/issues/23418

هذا أفضل بحوالي 100 مرة من الاضطرار إلى إزالة الحاويات العالقة بالقوة ، ولكنه لا يزال غير رائع.

يمكنني إعادة برورو على CentOS 7 على xfs.

نفس المشكلة هنا ، 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

أي قرار في الأفق بشأن هذا واحد؟ ما زلت أرى المشكلة وفشلت محاولاتي في العثور على عملية إبقاء الجهاز مفتوحًا. لا يبدو أن هناك أي عمليات تجعل الجهاز المشغول مفتوحًا.

شكرا.

(تحديث لتعليقي: لم يكن واضحًا في القراءة الأولى لسلسلة الرسائل ، ولكن يبدو أن تمكين الإزالة المؤجلة وتعيين MountFlags = slave قد يصلحها. سأقوم أيضًا بتحديث Docker إلى 1.13.)

يريد شخص ما لإصلاح هذه المشكلة أن يرى تعليق ravilr أعلاه ، التفاصيل أدناه:

في جميع الحالات ، تم تسريب نقطة تحميل الجهاز Thinpool للجهاز الخاص بالحاوية التي يتم إزالتها إلى مساحة اسم التحميل لمعرف بيانات آخر على المضيف الذي يتم بدء تشغيله بـ MountFlag = خاص / تابع.

بدأ ntpd.service بـ PrivateTmp = صحيح في RHEL
بدأت خدمة systemd-udevd بـ MountFlags = slave في RHEL
على الأجهزة المضيفة حيث تفشل عمليات حذف الحاويات ، تمت إعادة تشغيل أي من هاتين العمليتين بعد وقت بدء الحاوية المقابل.

either of these processes were restarted after the corresponding container start time. هي النقطة الأساسية ، فالملفات الموجودة في بعض الدلائل مثل "tmp" مستخدمة من قبل مساحة أسماء أخرى وليس فقط حاوية عامل التحميل ، لذلك لا يستطيع عامل الإرساء قتلهم بدون قسر.
يمكنك حل هذه المشكلة عن طريق إيقاف العمليات التي تمت إعادة تشغيلها أو تعيين معامل النظام PrivateTmp=true ليكون خطأ وإعادة تشغيله.

المرجع: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

KevinTHU ربما أسيء فهم تعليقاتك.

ولكن في حالتي (ubuntu 14.04) ، كل ما علي فعله لإصلاح ذلك هو إعادة تشغيل خدمة Docker نفسها
( service docker restart ). لم يتم تضمين "ntpd.service" أو "خدمة systemd-udevd".

هل هذا منطقي ؟

quexer بالطبع ، يمكن أن تؤدي إعادة تشغيل عامل

KevinTHU لا تؤثر إعادة تشغيل خدمة عامل الإرساء على أي حاوية قيد التشغيل. يمكنك أن تجرب ذلك بنفسك.

quexer يعتمد ذلك على التكوين الخاص بك. لكني أظن أنك إذا تركت الحاويات تعمل بوضع --live-restore ، فقد لا تحل المشكلة.
بشكل افتراضي ، سيوقف Docker جميع الحاويات عند الخروج ، وبعد ذلك إذا كان هناك أي شيء عندما يتعلق الأمر بالنسخ الاحتياطي ، فسيقتلهم أيضًا.

@ cpuguy83KevinTHU عذرا، هذا خطأي. أنت على حق ، إعادة تشغيل عامل الإرساء سيؤدي إلى إعادة تشغيل الحاوية بالكامل.

أنا الآن أحصل على هذا بانتظام مع أحد أجهزة VM الخاصة بي ، من فراغ. ومن المثير للاهتمام أن أحدهم أصبح قابلاً للحذف بعد أكثر من 8 ساعات من تركه بمفرده. ها هي معلوماتي:

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)

وانكسرت مرة أخرى.

لا أعرف ما إذا كان هذا مناسبًا ، لكن / var / log / messages لديه:

14 فبراير 16:58:49 نواة vrici: dev_remove: تم منع 40 رد نداء
14 فبراير 16:58:54 نواة vrici: dev_remove: تم منع 40 رد نداء
14 فبراير 16:58:59 نواة vrici: dev_remove: تم منع 40 رد نداء

الخطأ الآن هو:

استجابة خطأ من البرنامج الخفي: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e: فشل إزالة الجهاز dd81b82c875f4bcef819be83e9344c50794818a9e9b9b

الجهاز مشغول في مكان ما. هل يمكنك محاولة اتباع البرنامج النصي بعد الفشل ومعرفة المكان الذي قد يكون فيه الجهاز مشغولاً.

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
لم يتم العثور على وحدات تحكم
rlpowell @ vrici> sudo docker rm freq_build
استجابة الخطأ من البرنامج الخفي: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10: فشلت إزالة الجهاز 5f1095868bbfe85afccf392f6f4fbb65a12a24780

أوه ، يبدو أن هذا كان التجزئة الخطأ.

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

هذا ... غريب للغاية. ليس لدي أي فكرة عن سبب رؤية النواة لعملية php-fpm غير ذات صلة تمامًا لتبقى هذه التركيبات مفتوحة.

rlpowell نعم ، هذه هي المشكلة الكاملة وراء هذه المشكلة. هناك شيء ما يتسبب في عدم عمل مساحة اسم التحميل بشكل صحيح.

لقد وجدت ما يبدو أنه حل عملي هنا: http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

يعني هذا بشكل أساسي إضافة السطر التالي إلى ملف systemd docker.service الخاص بك:
MountFlags = خاص

يبدو أن هذا يعمل ، على الأقل بالنسبة للعينة الصغيرة من عمليات تشغيل عامل الإرساء التي قمت بها منذ نشرها. سيكون من الجيد أن يتمكن شخص ما يفهم تمامًا عامل الإرساء من شرح عواقب هذا العلم ، وأظن أن أنظمة الملفات التي تم تركيبها بعد بدء تشغيل عامل الإرساء قد لا تصبح متاحة للحاويات ، لكنني بصراحة لا أعرف. التكوين الخاص بنا مخصص للاستخدام على خادم بناء ويبدو أن هناك أشياء تعمل بشكل جيد.

مشكلة كبيرة جدًا ، تجعل عامل الإرساء غير قابل للاستخدام بشكل فعال في Centos 7 / RHEL - (وكان مفتوحًا لمدة 4 أشهر؟)
أي وقت مقدر؟

يجب شحن أحدث RHEL / centos مع MountFlags = slave في ملف docker.service.

rhvgoyal ليس هذا هو الحال: https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm

هذا موجود في الفرع الرئيسي ، ولكن الفرع 1.13.x و 17.03.x أيضًا لا يتوفران عليه.

بقدر ما أستطيع أن أقول أن هذه العلامة كانت في وحدة خدمة سابقة ولكن تمت إزالتها. لكني لم أجد لماذا. ربما تحل هذه العلامات المشكلة الحالية ولكنها تخلق مشكلات أخرى.

rlpowell SEAPUNK يبدو أن هذا ليس هو الحال في تثبيت ubuntu الخاص بي:

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

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

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

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

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

لقد كتبت مقالًا يوضح سبب عدم تمكن RHEL7 من دعم - استعادة الحياة حتى RHEL7.4 ولماذا يجب تشغيل عامل الإرساء داخل مساحة اسم تحميل مختلفة ثم المضيف.

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

+1 أريد تشغيل مساحة اسم تثبيت مختلفة وجعل جميع حوامل عامل الإرساء خاصة.
هناك بعض الأجزاء الصعبة هناك ، رغم ذلك.

إذا لم يكن لدى عامل الإرساء المنبع علامة مناسبة للتشغيل في MountFlags=slave فهذا خطأ وسيؤدي بسهولة إلى حدوث مشكلات في مساحات أسماء التحميل التي تتسرب بين الحاويات والمضيف ويمكن أن يؤدي إلى مشاكل في إزالة صور الحاوية.

FWIW ، تمت إزالة MountFlags=slave في https://github.com/docker/docker/pull/22806 ، بعد المراجعة من قبل مشرفي Red Hat ، ولكن يبدو أنه يتسبب في حدوث مشكلات ، لذا أتساءل عما إذا كان يجب التراجع عن ذلك حتى RHEL7.4؟

نعم ، لقد أزلناها وتسببت لاحقًا في حدوث مشكلات ، لذا خلصنا في أحد سلاسل المناقشة إلى أنه يتعين علينا إعادة تقديمها مرة أخرى. اعتقدت أنك فعلتها بالفعل. لا تتذكر أي موضوع كان على الرغم من ذلك.

thaJeztah نعم لقد كنا مخطئين ووجدنا مشاكل إضافية.

وكانت هذه المشكلات خاصة بالنواة الأقدم في المقام الأول. أحدث الألباب تعمل بشكل جيد.

اسمحوا لي أن أفتح العلاقات العامة لمناقشة الخيارات

تم فتح العلاقات العامة هنا ؛ https://github.com/docker/docker/pull/31490

نفس المشكلة ， docker 1.10.3 ， إصدار CentOS Linux 7.2.1511
dmesg ：
[1732917.246900] مخطط الجهاز: ioctl: غير قادر على إزالة عامل إرساء الجهاز المفتوح 8: 3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78
رسائل:
3 أبريل 3:32:34 A02-R05-I97-106 docker-current: time = "2017-04-03T03: 32: 34.346374677 + 08: 00" level = error msg = "خطأ في إزالة الطبقة المثبتة b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c013 "
3 أبريل 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 عاد الخطأ: فشل برنامج تشغيل devicemapper في إزالة نظام الملفات الجذر b0b1e839f366086fd7cff564feee385a3aed71a056db90 "

تتعدد:
find / proc / * / mounts | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
/ بروك / 159779 / يتصاعد: / ديف / مخطط / عامل ميناء-8: 3-5٬242٬884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / تصدير / عامل ميناء / devicemapper / كزاز الرضع / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS RW، relatime، nouuid، ATTR2، inode64، logbsize = 64K، سونيت = 128، العرض = 128 ، noquota 0 0
/ بروك / 159806 / يتصاعد: / ديف / مخطط / عامل ميناء-8: 3-5٬242٬884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / تصدير / عامل ميناء / devicemapper / كزاز الرضع / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS RW، relatime، nouuid، ATTR2، inode64، logbsize = 64K، سونيت = 128، العرض = 128 ، noquota 0 0
حاوية جديدة ：
فحص عامل ميناء 8777d36c94ec | grep Pid
"Pid": 159779 ،

// خطأي ， حلوه

ما هو المعرف "8777d36c94ec"؟ هذا هو معرف الحاوية للحاوية التي يتم إزالتها أو بعض الحاويات الأخرى؟

لذلك الجهاز مشغول لأنه لا يزال مثبتًا في الحاوية. لذلك لم يتم إيقاف الحاوية التي يتم إزالتها بعد. أو إذا كانت حاوية مختلفة ، فلا يجب أن تكون مرئية في حاوية أخرى.

ألست متأكدًا من نقطة التحميل "/ export / docker / devicemapper / mnt / ...." ومن الذي أنشأ هذا؟

على نظام Mint الخاص بي ، تؤدي الترقية من 17.03.1~ce-0~ubuntu-xenial إلى 17.04.0~ce-0~ubuntu-xenial حدوث هذه المشكلة بشكل متكرر.

قبل الترقية ، لم أواجهه مطلقًا. بعد أن كانت الترقية متكررة للغاية . يبدو أن الرجوع إلى الإصدار 17.03.1 قد تم حله.

تمامًا كملاحظة للآخرين الذين يقرؤون هذا الموضوع ، إذا كنت تقوم بتشغيل cAdvisor من Google ، فسترى هذه المشكلة عند محاولة إزالة حاوية. تحتاج أولاً إلى إيقاف cAdvisor ، ثم إزالة الحاوية ، ثم بدء cAdvisor مرة أخرى.

تضمين التغريدة نقوم بتشغيل خوادم بناء على أساس ubuntu والتي تقوم بتشغيل الحاويات طوال اليوم (عادةً ما يتم تشغيلها بواسطة عامل إنشاء السفن) ، وكنا نشهد هذه المشكلة عدة مرات في الأسبوع. الخوادم هي مزيج من مضمون و xenials. لقد بدأنا مؤخرًا في الترقية إلى 17.04.0 ~ ce ونشهد هذا يحدث عدة مرات في اليوم الآن.

لست واضحًا ما إذا كان MountFlags = slave ينطبق على ubuntu ، ولكن هذا ما أحاول بعد ذلك.

تضمين التغريدة
آسف ， خطأي。
لا يزال آخرون مثبتين في الحاوية الخاصة بي。

فقط واجهت نفس المشكلة على:

• عامل ميناء: إصدار Docker 17.03.1-ce ، بناء c6d412e
• نظام التشغيل: الإصدار 7.3 من خادم Red Hat Enterprise Linux Server (Maipo)
• النواة: 3.10.0-514.6.1.el7.x86_64
• ntpd: 4.2.6p5

عمل systemctl restart ntpd على حل المشكلة على الفور.

xeor
ما هو ملف وحدة خدمة docker.service الخاص بك MountFlags ؟

لا يوجد MountFlags في ملف /usr/lib/systemd/system/docker.service ، لكن systemctl show docker يظهر MountFlags=0 .

نفس الشيء بالنسبة لـ ntpd.service . يحتوي هذا أيضًا على PrivateTmp=true تحت المقطع [Service] (إذا كان هذا الأمر مهمًا).

اركض مع MountFlags = slave في الوقت الحالي.

rhvgoyal فحص ملف docker.service بلدي. لكن القيمة الخاصة بك محددة بالفعل:

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

باستخدام أحدث redhat (3.10.0-514.16.1.el7) / عامل إرساء (1.12.6-16.el7)

ماذا عن MountFlags = خاص؟ هل يمكن أن تشرح الفرق بين الخاص والعبد؟

أرى هذه المشكلة حاليًا في RHEL / CentOS 7.3 ، kernel 3.10.0-514.16.1.el7.x86_64 ، مع إصدار Docker 17.05.0-ce ، بناء 89658be. لقد رأينا هذه المشكلة متقطعة خلال العام الماضي.

ليس لدينا خيار MountFlags في /etc/systemd/system/multi-user.target.wants/docker.service أيضًا. هل يجب إضافة "MountFlags = slave" هناك؟

أرى تعليقات تقول أن هذه المشكلة تحدث في Centos و RHEL و Ubuntu. هل أنظمة التشغيل الأخرى آمنة من هذه المشكلة بالذات ، مثل Debian أو ContainerLinux أو SUSE؟

earwax أي شيء بنواة أحدث (> = 3.15) يجب أن يعمل بشكل أفضل.
ولكن هناك دائمًا مواقف يمكنك إنشاؤها حيث يحدث هذا الخطأ.
أيضًا ، هناك عدة طرق مدرجة في التعليقات هنا للتخفيف من حدتها.

أرى هذه المشكلة على SUSE ... لكن لم أجد حلًا لها ... أرى أن هذا يحدث غالبًا على المزود: AZURE

نجد أيضًا هذه المشكلة ، عندما قمنا بتحديث dockerd من 1.12.6 إلى 17.05. لا يمكن حذف جميع الحاويات القديمة بدون "-f" ، فقد كان لهذه الحاويات ميزة مشتركة وهي أنه لم يتم إيقافها جميعًا عند تحديث dockerd ، لأن لدينا التكوين "--live-response". أعتقد أن هناك بعض المشاكل هنا.

لا تزال هذه مشكلة في 17.06 ، لمعلوماتك ، على الأقل مع CentOS 7.

@ MGD1981 يجب إصلاح هذا الخطأ ، فنحن نستخدم centos 7 بنفس الطريقة ، ووجدنا أنه ليس فقط الحاويات القديمة التي تم إنشاؤها قبل تحديث عامل الإرساء بها مشكلة "الجهاز مشغول" ، ولكن أيضًا الحاويات الجديدة التي تم إنشاؤها ، وهذا أمر بالغ الأهمية حقًا ، ونعمل على حلها عن طريق إضافة "MountFlags = slave" إلى docker.service. ومع ذلك ، لا نعرف ما إذا كانت هذه المعلمة ستؤدي إلى مشكلة أخرى.

نعم ، جرب هذا الآن في بيئة ضمان الجودة لدينا. سيتم إيلاء اهتمام وثيق
إلى الجبال. هل هناك خطر محتمل على FS للحاوية
"نسيت" مع هذا الإعداد ، بمرور الوقت يملأ المضيف بالأقراص
من الحاويات الميتة؟

في يوم الإثنين ، 3 يوليو 2017 ، الساعة 10:38 مساءً ، كتب KevinTHU [email protected] :

@ MGD1981 https://github.com/mgd1981 يجب إصلاح هذا الخطأ ، نحن كذلك
باستخدام centos 7 نفسه ، ونكتشف أنه ليس فقط الحاويات القديمة
تم إنشاؤه قبل تحديث عامل الإرساء به مشكلة "الجهاز مشغول" ، ولكن أيضًا ملف
حاويات تم إنشاؤها حديثًا ، هذا أمر بالغ الأهمية حقًا ، ونحن نعمل على حله
إضافة "MountFlags = slave" إلى docker.service. ومع ذلك ، لا نعرف ما هو الطقس
هذه المعلمة ستجلب بعض المشاكل الأخرى.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/27381#issuecomment-312766596 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.

@ MGD1981 نعم ، يبدو أن هناك أقراصًا على المضيف لم تعد مستخدمة. انظر # 33025

ceecko لن يحدث هذا بعد الآن اعتبارًا من 17.06 ، على الرغم من أنك إذا قمت بتمكين الإزالة / الحذف المؤجل ، فقد لا يتم تنظيفه على الفور.

@ cpuguy83 لطيف! هل سينظف الأقراص القديمة التي خلفتها الإصدارات السابقة أيضًا؟

@ cpuguy83 هل تم إصدار 17.06 حتى الآن؟ (إنه يوليو بالفعل ، لذا 17.07؟) لم يتم العثور عليه في صفحة إصدارات جيثب.

ravilr انها خارج. تأتي الإصدارات من github.com/docker/docker-ce.

ceecko لا أعتقد ذلك.

@ cpuguy83 شكرا. ملاحظات إصدار 17.06 لا يبدو أنها تذكر أي إصلاحات عامة بخصوص هذه المشكلة. ما هو الإصلاح لمعالجة هذا؟ شكرا لك مرة أخرى.

ravilr هذا العلاقات العامة https://github.com/moby/moby/pull/31012

أعمل 17.06.0-ce على CentOS 7 (مع تخزين رقيق للمجمع) وهذا يحدث كثيرًا مؤخرًا.

+ 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

هل هذا مع أو بدون MountFlags=slave @ AaronDMarasco-VSI؟ CentOS 7.3؟

17.06 لا يصلح المشكلة الأساسية ، إنه أفضل في التعامل معها.
إنني أنظر إلى ما إذا كان هناك شيء يقوم به عامل الشحن (أو بعض المكونات الفرعية مثل containerd) مما يؤدي إلى تفاقم المشكلة.

esabol لا ... خاص؟

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) 

حسنًا ، @ AaronDMarasco-VSI ، أنصح بتغيير ذلك إلى MountFlags=slave ، مما أدى إلى تحسين الوضع بالنسبة لنا ، لكننا ما زلنا في 17.05 وأعتقد أنني رأيت مكانًا لا تريد استخدامه MountFlags=slave مع dm.use_deferred_removal ؟ ربما شخص آخر سوف يعلق ويؤكد.

أنا أستخدم docker 17.03 على centos 7.3 و kernel 4.10. ولقد كنت أرى هذا الخطأ كثيرًا. فيما يلي بعض التفاصيل الإضافية حول MountFlag.

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

نفس المشكلة هنا مع Debian 8. إنها تكسر CI لدينا ، هل من الممكن حلها ؟؟

@ thg303 حاول إيقاف تشغيل dockerdeamon ، إن أمكن وحاول تنظيف / إزالة نظام ملفات الجذر الذي يحدث في ملف السجل (rm / var / lib / docker / .....). لكن يجب أن تأخذ لقطة / نسخة احتياطية قبل :-)

نفس المشكلة هنا مع 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.

لدي هذه المشكلة في كل مرة يتم تحديث عامل الميناء في centos7. أقوم بإعادة تشغيل عامل الإرساء ثم يعمل كل شيء بشكل جيد.

نفس الشيء بالنسبة لي في Fedora 26 مع Docker 17.06.0-ce. إعادة تشغيل عامل الإرساء لم يحل المشكلة.

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

على محمل الجد في عام الآن وما زال هذا الخطأ هنا؟

NeckBeardPrince من فضلك لا تضيع وقتنا مع مثل هذا التعليق غير المجدي.
إذا كنت ترغب في المساعدة في حلها ، فهذا رائع. إذا كنت ترغب في الإبلاغ عن المزيد من البيانات حول المشكلة ، فهذا رائع.

بخلاف ذلك ، هناك طريقتان للتغلب على هذه المشكلة تم نشرهما هنا.

لا يتم شحن ملف وحدة systemd بـ 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

آخر مرة واجهتني هذه المشكلة ، كان ntpd هو الذي يحمل الحوامل.
اليوم ، أواجه نفس المشكلة ، وهذه المرة ، كانت حالة mariadb تعمل على المضيف وهذا هو السبب.

• محرك عامل ميناء 17.05.0.ce-1.el7.centos.x86_64
• mariadb-server-5.5.56-2.el7.x86_64

مثال لإيجاد proc الذي يحمل الحوامل ....

# 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

بعد إعادة تشغيل mariadb ، تخلت عن نقاط التثبيت ، لكنها استحوذت على الكثير منها عندما بدأت.

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

ترجع معظم حالات فشل الإزالة إلى أن نقطة التحميل (ومن ثم الجهاز) مشغولة في بعض مساحات أسماء التحميل الأخرى. أعتقد أن اتباع العلاقات العامة المقترحة سيساعد في حل هذه المشكلة إذا كانت النواة جديدة بما فيه الكفاية.

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

إذا كنت تقوم بتشغيل kernel قديم ، فقد قمنا بكتابة oci-umount استدعاء إضافي لتقليل مشاكل تسريب التحميل.

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

rhvgoyal هل لديكم خطة بشأن تحرير عامل الإرساء لتضمين هذه العلاقات العامة؟ ما زلنا نتعامل مع driver "devicemapper" failed to remove root filesystem على أساس منتظم.

إصدار CentOS Linux 7.4.1708 (Core)
3.10.0-693.5.2.el7.x86_64
17.06.2 م

يبدو أنه تم إصلاحه نهائيًا

نقوم بتشغيل إصدار Docker 17.09.0-ce وما زلنا نواجه نفس المشكلة.

نواجه هذه المشكلة أحيانًا على Oracle Linux: مع إصدار عامل الإرساء 17.03.1-ce (من مستودعات 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

تم إصلاح كل ما سبق من خلال TDA للمشروع ، لذلك لا يمكننا تغيير أي منها في الوقت الحالي.

90٪ من بيئاتنا الأخرى هي Centos 7.3 / 7.4 ، ولم نر المشكلة هناك.

تمكنت للتو من حل مثيل لهذه المشكلة مع Docker 17.05 على نظام Linux على 4.11.9
بواسطة

1. docker rm -f [myContainer] (الفشل مع driver "devicemapper" failed to remove root filesystem كالمعتاد)
2. ls /var/lib/docker/devicemapper/mnt/

هذا جعل الحاوية تختفي أخيرًا (لست متأكدًا من السبب).

MonsieurWave لا يصدق كما يبدو ، خدعة "ls" عملت بشكل مثالي بالنسبة لي عندما لم يكن كل شيء آخر!

سيبلغ docker rm -f [container] عن حدوث فشل ولكن في النهاية سينظف الحاوية ونظام الملفات. الأمر ls هو رنجة حمراء ، كل ما تحتاجه حقًا هو الانتظار بضع ثوان. ولكن أفضل من ذلك هو استخدام MountFlags=slave . والأفضل هو إيقاف تشغيل devicemapper واستخدام overlay2 بدلاً من ذلك.

والأفضل هو إيقاف تشغيل devicemapper واستخدام overlay2 بدلاً من ذلك.

لقد استخدمنا Docker على CentOS 7.x (حاليًا عند 7.4) لأكثر من عام الآن. عندما قمنا بتثبيت Docker لأول مرة ، قال كل شيء وكل شخص إن عليك استخدام devicemapper مع Direct-lvm للحصول على أفضل أداء واستقرار. https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ لا يزال يقول أنه يتعين عليك استخدام devicemapper على CentOS مع Docker EE. لحسن الحظ ، نستخدم Docker CE ، لذا يمكننا التبديل إلى overlay2. أشعر أن أفراد Docker قد تراجعوا في التغيير الافتراضي من devicemapper إلى overlay2 على CentOS في v1.13.0 / 1 مع القليل من الضجة أو المناقشة. هل هناك أي معلومات موثوقة حول أداء / استقرار التراكب 2 مقابل جهاز رسم الخرائط (مباشر - lvm) في CentOS 7؟ لم يعثر موقع googling الخاص بي على الكثير ....

لقد مررنا بوقت سيء للغاية مع مخزون CentOS 7.2 نواة (3.10.x frankenstein). الكثير من الحوادث. كنا نشغل Kubernetes في بيئة مطورة ، لذلك كان زخم حاوياتنا مرتفعًا جدًا ، ولكن حتى في التركيبات الهادئة نسبيًا وجدنا أن مجموعة CentOS + overlay غير مستقرة للغاية. تشغيل نواة أعلى من 4.10+ مع overlay2 أفضل بكثير . لم تجرب إصدار CentOS الأحدث.

ستحتاج إما إلى استخدام نظام ملفات أساسي يكون ext4 أو XFS منسقًا بـ "-n ftype = 1". سيتم تشغيل Docker إذا كان لديك XFS مهيأ بشكل غير صحيح ، لكن النتائج ستكون غير متوقعة.

نعم ، لقد قمت منذ فترة طويلة بالتبديل إلى overlay2 ، وأوصي أي شخص لا يزال يستخدم devicemapper يمكنه استخدام overlay2 للتبديل ، بما أنه حتى هذه المشكلة جانباً ، فقد قرأت أن devicemapper هو برنامج تخزين سيئ للغاية لرسو السفن بشكل عام.

أدت إعادة تشغيل ntpd إلى إصلاح المشكلة التي كنت أواجهها ... محيرة للغاية. هل هناك أي تكوين daemon.json "موصى به" لعامل الإرساء على Centos7؟

بعض التحسينات تنزل على خط الأنابيب.

على وجه التحديد ، يبدو أن المشكلة مع خدمات النظام الأخرى هذه هي حالة سباق مع إعداد مساحات أسماء التحميل (لخدمات النظام الأخرى) ومحاولة عامل الرصيف الحفاظ على خصوصية عمليات التحميل الخاصة به ... والهدف من ذلك هو أن يحافظ Docker على حوامله من التسرب إلى الحاويات ، لسوء الحظ ، يتسبب ذلك في حدوث تسريبات في مكان آخر وينتهي به الأمر في الواقع إلى الاحتفاظ بمراجع خاصة لنقاط التثبيت هذه مما يعني أنه لا يمكن إلغاء تركيبها في مساحات الأسماء هذه إلا يدويًا أو عند إعادة تشغيل العملية.

بالإضافة إلى ذلك ، كانت هناك بعض التغييرات الأخيرة للتعامل مع ظروف السباق باستخدام MS_PRIVATE mount propagation في كل من runc و docker.
هل سيكون الإصدار التالي مثاليًا؟ ربما لا ... لكني أتوقع أن يتحسن هذا.

حصلت على نفس الشيء تمامًا مثل ceecko مع عامل

تعمل هذه الإصدارات على إصلاح المشكلة تمامًا بالنسبة لي ، بما في ذلك --live-restore

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

esabol قمنا بتقييم التحول إلى overlay2 بعد أن قمنا بالترقية إلى CentOS 7.4. للأسف إنه عمل كثير جدًا. الأقسام التي يمكننا استخدامها لتخزين البيانات هي XFS وقبل 7.4 ، غاب خيار تنسيق CentOS الافتراضي XFS عن معلمة واحدة (نسيت أي منها) لتكون قادرًا على دعم overlay2 في الأعلى. هذا يعني أنه سيتعين علينا إعادة تهيئة القسم حتى نتمكن من استخدام overlay2 أعلى XFS. هذا هو الوقت الذي سيكلفنا فيه التبديل إلى overlay2 الكثير من العمل لتجنب التوقف ، وقد ساعدت أحدث 7.4 kernel + Docker 17.09 والتوصيات المذكورة أعلاه لتكوين LVM كثيرًا في تجنب المشكلة معظم الوقت.

ملاحظة: يُظهر docker info تحذيرًا كبيرًا من الدهون مفاده أن تشغيل Overlay2 على XFS بدون هذه الخيارات المحددة غير مدعوم وستتم إزالته في إصدار مستقبلي.

https://github.com/moby/moby/pull/34573 تم إصدار الإصلاح في 17.09.1 ​​م بإصدارات 17.12.0 م

jcberthon لقد قمنا مؤخرًا docker run --rm . كانت القشة الأخيرة بالنسبة لنا لمطور devmapper هي الإصدار رقم 20401. لم يكن التبديل إلى overlay2 صعبًا للغاية ، ولكن لدينا الكثير من المساحة الخالية على القرص. لقد كتبت نصًا إلى docker save جميع صورنا لكرات القطران ونصًا آخر إلى docker load لكل كرات القطران. لقد انتهينا في 2-3 ساعات. أعلم أن الأمر يبدو وكأنه متاعب ويمكن أن يحدث إذا لم يكن لديك مساحة كافية على القرص ، ولكن الأمر يستحق ذلك على المدى الطويل ، على ما أعتقد. حظا طيبا وفقك الله!

تم إصلاح هذا في 17.12.1

شكرا لكم جميعا.

قبل الإصدار النهائي ، ستؤدي إعادة تشغيل العقدة المادية إلى حل المشكلة

ravilrKevinTHU بخصوص تعليقك https://github.com/moby/moby/issues/27381#issuecomment -277148106 و https://github.com/moby/moby/issues/27381#issuecomment -267547259 لقد لوحظ أن تغيير ملف وحدة الرصيف على RHEL إلى PrivateTmp=true يصلح المشكلة أيضًا. هل من الممكن أن ترى شيئًا مشابهًا؟

MohdAhmad لم يجرب ذلك أبدًا ، لكنني أعتقد أن هذا ربما يكون الإرساء مخصص لعمال الإرساء فقط ، وربما حل هذه المشكلة بشكل أفضل.

أجد نفس المشكلة. لأنني فتحت المجلد ، أغلق النافذة لحلها.