Я пытаюсь понять, что работает с Centos + Vagrant, но не на наших провайдерах RHEL (Red Hat Enterprise Linux Server версии 6.5 (Сантьяго)). перезагрузка службы sudo docker:
Stopping docker: [ OK ]
Starting cgconfig service: Error: cannot mount cpuset to /cgroup/cpuset: Device or resource busy
/sbin/cgconfigparser; error loading /etc/cgconfig.conf: Cgroup mounting failed
Failed to parse /etc/cgconfig.conf [FAILED]
Starting docker: [ OK ]
Служба запускает достаточно okey, но изображения не могут работать. Когда я пытаюсь, отображается ошибка сбоя при установке. И журнал запуска также дает предупреждение или два. Что касается kernelwarning, centos дает то же самое и не имеет проблем, поскольку Epel должен решить это:
WARNING: You are running linux kernel version 2.6.32-431.17.1.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.
2014/08/07 08:58:29 docker daemon: 1.1.2 d84a070; execdriver: native; graphdriver:
[1233d0af] +job serveapi(unix:///var/run/docker.sock)
[1233d0af] +job initserver()
[1233d0af.initserver()] Creating server
2014/08/07 08:58:29 Listening for HTTP on unix (/var/run/docker.sock)
[1233d0af] +job init_networkdriver()
[1233d0af] -job init_networkdriver() = OK (0)
2014/08/07 08:58:29 WARNING: mountpoint not found
Кто-нибудь имел успех в преодолении этой проблемы, или я должен бросить полотенце и ждать, пока провайдер обновит RHEL 7?
В итоге я задал тот же вопрос в Google Groups и, в конце концов, нашел решение с некоторой помощью. Для меня это было так:
umount cgroup
sudo service cgconfig start
Проект создания Docker-работы был все же остановлен. Позже проблема подключения к сети для контейнеров. Это заняло много времени, чтобы решить и пришлось отказаться.
У меня такая же проблема.
(1) проверить статус cgconfig
#/etc/init.d/cgconfig status
если он остановлен, перезапустите его
#/etc/init.d/cgconfig restart
проверить, запущен ли cgconfig
(2) проверить, что cgconfig включен
# chkconfig --list cgconfig
cgconfig 0: выкл. 1: выкл. 2: выкл. 3: выкл. 4: выкл. 5: выкл. 6: выкл.
если cgconfig выключен, включите его
(3) если все еще не работает, могут быть некоторые модули групп отсутствуют. В файле .config ядра сделайте menuconfig, добавьте эти модули в ядро и перекомпилируйте и перезагрузите
после этого, он должен быть ОК
Таким образом, я потратил целый день, пытаясь прикрепить докер, чтобы работать на моем vps. Я столкнулся с этой же ошибкой. В основном, это было связано с тем, что OpenVZ не поддерживал докер-контейнеры до двух месяцев назад. В частности, это обновление RHEL:
https://openvz.org/Download/kernel/rhel6/042stab105.14
Предполагая, что это ваша проблема или какая-то ее вариация, бремя ее решения лежит на вашем хосте. Они должны будут выполнить следующие шаги:
В моем случае
/etc/rc.d/rc.cgconfig start
генерировал
Запуск службы cgconfig: Ошибка: невозможно установить cpu, cpuacct, memory to /cgroup/cpu _and_mem: устройство или ресурс занят /usr/sbin/cgconfigparser; Ошибка загрузки /etc/cgconfig.conf: Сбой сборки группы Не удалось выполнить parse/etc/cgconfig.conf
Мне пришлось использовать:
/etc/rc.d/rc.cgconfig restart
и это автоматически затухающие и монтируемые группы
Остановка службы cgconfig: запуск службы cgconfig:
похоже, что служба cgconfig не работает, поэтому проверьте ее!
# /etc/init.d/cgconfig status
# mkdir -p /cgroup/cpuacct /cgroup/memory /cgroup/devices /cgroup/freezer net_cls /cgroup/blkio
# cat /etc/cgconfig.conf |tail|grep "="|awk '{print "mount -t cgroup -o",$1,$1,$NF}'>cgroup_mount.sh
# sh ./cgroup_mount.sh
# /etc/init.d/cgconfig restart
# /etc/init.d/docker restart
Эта ситуация возникает, когда ядро загружается с помощью cgroup_disable = memory и /etc/cgconfig.conf содержит memory =/cgroup/memory;
Это приводит к тому, что только набор /cgroup/cpuset устанавливается вместо полного набора.
Решение: либо удалите cgroup_disable = память из ваших параметров загрузки ядра, либо закомментируйте память =/cgroup/memory; от cgconfig.conf.
При запуске службы cgconfig используются mount и umount, для чего требуется дополнительный привилегированный удар из докера.
Подробнее см. флаг --privileged=true здесь.
Мне удалось преодолеть эту проблему, запустив мой контейнер: docker run -it --privileged=true my-image.
Протестировано в Centos6, Centos6.5.