Это странно, и хотя у меня есть обходной путь, я бы предпочел постоянное исправление.
У меня есть небольшая группа машин с графическим процессором под управлением Ubuntu 14.04, которые я использую в качестве рабочих для облачной службы, которая осуществляется через образы Docker. у меня есть nvidia-docker установлен на всех рабочих машинах, так что у докера есть доступ к графическим процессорам. Рабочие машины также функционируют как отдельные серверы, на которых члены лаборатории могут проводить эксперименты напрямую (академическая среда, облачная служба является экспериментальной и т. Д.). Для последней цели все машины автоматически монтируют отдельные пользовательские ресурсы через NFS. Недавно мы перешли на автоматическое монтирование со статической конфигурации fstab, и я все еще привыкаю к этому - вполне возможно, здесь есть какая-то очевидная проблема, которую я не вижу, потому что я автомонтирую n00b. Наконец, я ничего не настроил для образов докеров, чтобы иметь доступ к общим ресурсам NFS, поэтому теоретически не должно быть связи ... теоретически.
На этой неделе один из сотрудников нашей лаборатории сообщил о Too many levels of symbolic links
ошибка при попытке доступа к их общему диску с одного из компьютеров GPU. Они вообще не используют докер (насколько им известно). В их дереве нет сомнительных символических ссылок (через find -type l
), так что это должно быть что-то еще, переходящее в странное состояние. Точка монтирования выглядит так под ls -l
из родительского каталога:
dr-xr-xr-x 2 root root 0 Dec 5 18:38 labmember1
что кажется ... плохим? корень: корень 555, правда? и когда вы пытаетесь его просмотреть, вы действительно получаете:
$ cd /path/to/labmember1/
-bash: cd: /path/to/labmember1/: Too many levels of symbolic links
Похоже, что общий ресурс на самом деле не смонтирован - он не отображается в / etc / mtab, и (как и следовало ожидать) попытки отключить его вручную сообщают:
$ sudo umount /path/to/labmember1/
umount: /path/to/labmember1/: not mounted
Перезапуск autofs (service autofs restart
) Ничего не сделал.
В то время я думал, что это не имеет отношения к делу: докер повсюду извергал veth-интерфейсы. Это была машина, которая активно использовалась в качестве облачного работника, поэтому я решил, что это наше облачное программное обеспечение. Теперь я не уверен.
Сегодня Too many levels of symbolic links
сбой произошел на другом компьютере с графическим процессором, на котором установлено приложение docker / nvidia-docker, но не запускается программное обеспечение облачного рабочего. И вот, veth-интерфейсы повсюду, хотя их гораздо меньше, чем на компьютере с облачным рабочим столом.
По прихоти остановил службу докеров (service docker stop
). Магия! Лежа устанавливается нормально, и член нашей лаборатории может снова использовать свои вещи. Акция остается в рабочем состоянии после повторного запуска докера.
Поэтому я могу решить эту проблему, перезапустив докер, если (когда) это произойдет снова, но я хотел бы знать
root@slave2:~# cd /home/client/
-bash: cd: /home/client/: Too many levels of symbolic links
решение:
root@slave2:~# cd /home/
root@slave2:/home# umount client
а затем перемонтируйте путь к файлу.
Как вы определили параметры монтирования для autofs
на /etc/auto.master
вы делаете прямое или косвенное автомонтирование?
Также ты autofs
полностью в контейнере Docker с --privileged
опция добавлена в команду запуска докера? Используя этот подход, вы сможете без проблем выполнять монтирование NFS.
Обратите внимание, что привязка установки autofs
монтировать в контейнер с независимым запущенным демоном autofs невозможно, потому что это может конфликтовать с демоном autofs, запущенным в исходном пространстве имен.
Для непрямых креплений, бега autofs
в корневом пространстве имен обеспечивает автоматическое монтирование контейнеров Docker путем привязки монтирования верхнего уровня autofs к контейнерам с опцией тома Docker, которая должна работать в основном должным образом.