Can't run docker hello-world: mountpoint for devices not found

Эта команда использует вашу команду для поиска зараженных файлов и передает список в xargs, который запускает выражение в первой строке.

find * -type f -name "*.php" -exec grep -l "cnajwp =" {} \; |
xargs sed -i -E '1s/^(<\?php) \$ocnajwp =.*$/\1/'

Согласно вашему образцу входного файла, это должно сработать.

Так как за это время вы нашли файлы, в которых заражение было размещено несколько иначе, и у вас остались файлы, в которых обе первые строки содержат , вы можете запустить следующее, чтобы очистите эти файлы:

find * -type f -name "*.php" -exec \
gawk -i inplace 'NR==2 && /^<\?php$/ {next} 1' {} \;
12
15.12.2015, 17:59
1 ответ

Я добавлю сюда еще один ответ для тех, кто увидит это в 2020 году в Debian, поскольку моего решения этой проблемы не было ни в одном из результатов поиска, найденных при поиске в Google строки ошибки «точка монтирования для устройств не найдена».

Фон:

  • Debian 8.11 работает на Google Cloud Platform
  • 5 недель назад была установлена ​​рабочая установка Docker с двумя запущенными контейнерами

Внезапно понял, что что-то заставило контейнеры рухнуть. Единственная отдаленно вероятная причина, которую я мог придумать, заключалась в том, что я удалил родительскую папку на хосте, в которой подпапка была сопоставлена ​​​​как том. Другой причиной может быть установка дополнительного физического устройства.

Конечным результатом в любом случае было то, что попытка запустить любой контейнер Docker привела к сообщению об ошибке, показанному в вопросе ("mountpoint for devices not found" ), и без перезагрузки (и, следовательно, обновления ядра ).

Шаги, которые я предпринял для устранения проблемы, были

  1. Осмотрите журналы:journalctl -xn | less. На самом деле не содержал слишком много дополнительной информации
  2. Остановить демон Docker(/etc/init.d/docker stop).
  3. Добавить файл /etc/docker/daemon.json, единственным содержимым которого было{"debug": true}
  4. Попробуйте перезапустить демон Docker и увидите, что он не работает
  5. Просмотрите журналы, которые теперь будут заполнены гораздо большей информацией

Эти cgroupсвязанные ошибки привели к ответу:

Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964631675Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964654637Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964667575Z" level=warning msg="Unable to find blkio cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964680057Z" level=warning msg="Unable to find cpuset cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964750643Z" level=warning msg="mountpoint for pids not found"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.980250151Z" level=debug msg="Cleaning up old mountid : start."
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: Error starting daemon: Devices cgroup isn't mounted

Хорошо, кое-что о cgroupsи монтаже. Это привело меня к обходному пути для другой проблемы cgroups , который можно было бы применить в этом случае, из которых единственными командами, которые, казалось, имели эффект, были

  1. /etc/init.d/docker stop
  2. cgroupfs-mount
  3. /etc/init.d/docker start

Теперь при повторном запуске Docker журналы по-прежнему содержали несколько строк ошибок, связанных с cgroup:

Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258571633Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258591020Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258937091Z" level=warning msg="mountpoint for pids not found"

Но половина из них (blkio,cpuset)исчезла, и что более важно, следующая строка читалась:

Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.259420798Z" level=info msg="Loading containers: start."

И, наконец,

Unit docker.socket has finished starting up.

Таким образом, перемонтирование cgroup решило проблему. Нет необходимости перезагружаться.

1
27.01.2020, 19:55

Теги

Похожие вопросы