• Docker: devicemapper fix for “device or resource busy” (EBUSY) Cannot start container


    受众:
    本文适用于熟悉码头工作的人员,并希望解决使用devicemapper存储/图形驱动程序时遇到的特定问题。

    概述:
    虽然这不是专门用于设计师的问题,但是目前参与此驱动程序的技术人员会受到此影响。

    使用'devicemapper'存储驱动程序时看到的几个常见问题是在尝试停止和/或删除contianer时。
    在docker守护程序日志中,您可能会看到如下输出:

    [error] deviceset.go:792 Warning: error waiting for device ac05cffda663a01cbc37879bc146fcd68d0f95b5b141f60da2b64579add1f4ef to close:
    Timeout while waiting for device ac05cffda663a01cbc37879bc146fcd68d0f95b5b141f60da2b64579add1f4ef to close

    或如:

    Cannot destroy container ac05cffda663: Driver devicemapper failed to remove root filesystem ac05cffda663a01cbc37879bc146fcd68d0f95b5b141f60da2b64579add1f4ef: Device is Busy
    [8ad069f7] -job rm(ac05cffda663) = ERR (1)
    [error] server.go:1207 Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container ac05cffda663: Driver devicemapper failed to remove root filesystem ac05cffda663a01cbc37879bc146fcd68d0f95b5b141f60da2b64579add1f4ef: Device is Busy
    [error] server.go:110 HTTP Error: statusCode=500 Cannot destroy container ac05cffda663: Driver devicemapper failed to remove root filesystem ac05cffda663a01cbc37879bc146fcd68d0f95b5b141f60da2b64579add1f4ef: Device is Busy

    诊断:
    幕后发生的事情是,devicemapper已经建立了一个新的瘦快照设备来装载容器。
    在该容器的寿命期间,主机上与docker无关的另一个PID可能已经从根命名空间启动并取消共享一些命名空间,即mount命名空间(CLONE_NEWNS)。 在此非共享主机PID中引用的安装程序中,它包含瘦快照设备及其用于容器运行时的安装。

    当容器停止并卸载时,它可能会从根命名空间卸载设备,该umount不会传播到非共享主机PID。
    当容器被删除时,devicemapper尝试删除瘦快照设备,但是由于非共享主机PID包含对其mountinfo中的设备的引用,内核会将设备看作是忙碌(EBUSY)。 尽管事实上,根安装名称空间的安装可能不再显示此设备并挂载。

    再生产:
    1)启动docker守护程序(使用调试和强制devicemapper):`sudo docker -d -D -g devicemapper`
    2)启动一个容器:`sudo docker run -it busybox top`
    3)运行带有unshared mount命名空间的pid:
    3.a)编译一个简单的C应用程序:http://pastebin.com/HfSn8udJ
    3.b)使用unshare(1)实用程序:`sudo unshare -m top`
    4)停止或杀死步骤#2中的容器
    5)看docker守护进程日志

    如果在docker守护程序尝试删除容器时,从#3中删除/退出非共享应用程序,则守护程序可以很好地清理容器。 否则有左侧(/ var / lib / docker)中的cruft,并且守护程序将没有要删除的容器的记录。

    调查:
    可视化此继承的工具并不真正存在,因此导出弊端可能需要一些努力。
    有时候,“perf”工具可以快速指出罪魁祸首。 就像是:

    perf probe -a clone_mnt
    perf record -g -e probe:clone_mnt -aR docker -d
    [...]
    perf report

    解决方法:

    先找出没有umount的路径:

    cat /proc/mounts | grep "mapper/docker" | awk '{print $2}'

    umount 查找出来的路径:

    umount /var/lib/docker/devicemapper/mnt/ddf1dd91bbf46dc648268327f8f7c6fffaf2f19cda5cf1d97fdc701016d4332c

    修改完成后记得重启docker服务。

    原文地址:http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

  • 相关阅读:
    Redis面试题(46题)
    公共组件及脚手架webpack模板
    css3中@font-face模块自定义字体
    字段加密实践(django-fernet-fields)
    django导入导出excel实践
    vue-loader和单页组件介绍
    Axios介绍和使用
    微服务架构理解及微服务架构局限性
    v-model的双向数据绑定(表单)
    eureka集群
  • 原文地址:https://www.cnblogs.com/boonya/p/7373315.html
Copyright © 2020-2023  润新知