Размонтировать устройство или ресурс занят; уже попробовал: mount, lsof, fuser, exportfs, ps axf
Как часть автоматизированной системы создания виртуальных машин блочное устройство монтируется во временную папку ( /tmp/ что угодно) . Различные сценарии устанавливают и настраивают виртуальную машину до ее первого запуска.
Недавно что-то изменилось, временное монтирование занято и отказывается от монтирования. Пытаясь определить, что еще может держать файл открытым, я проверил:
Тесты запускаются как root
- крепление
- лсоф | grep /tmp/
- фьюзер -m / tmp /...
- exportfs -rv
- Перезапуск демона, который все равно запускает сценарии создания...
- ps axf
- таблица dmsetup
- потерять -a
- fuser -vm /tmp/tmp.random-chars/ (возвращает две строки)
- КОМАНДА ПОЛУЧЕНИЯ PID
- /tmp/tmp.random-chars: монтирование корневого ядра /tmp/tmp.random-chars
Ни один из вышеперечисленных тестов не дал результатов, указывающих на использование файловой системы, однако umount -f по-прежнему выдает сообщение "Устройство или ресурс занят" / "Устройство занято".
Какие еще тесты мне следует попробовать, чтобы я мог найти истинную основную причину и, таким образом, надеяться исправить застрявшее крепление без перезагрузки в системе, которую я не могу перезапустить на некоторое время, а также предотвратить повторное возникновение?
Также / сомнительно / (но я не знаю, как проверить), что модули ядра из временного монтирования загружены, так как во временном монтировании установлена другая версия Linux, нежели работает хост.
правки
- Из различных результатов поиска видно, что / modules / просто считываются в память. Я не знаю, может ли ядро иметь открытые файлы и как получить доступ к любому такому списку.
- Добавлен dmsetup / losttup в списки "тестов, которые не показывают проблем"
- fuser -vm как предложено в freenode ##linux
3 ответа
Если это часть процесса сборки, я предполагаю, что вам все равно придется перезагрузиться в какой-то момент. Попробуйте вставить "ленивое" размонтирование в процесс. использование umount -l /tmp и посмотрите, поможет ли это вам преодолеть этот барьер в процессе.
Одна причина umount может произойти сбой, если основной IP-адрес удаленного устройства изменился.
Я видел, как это происходило, когда я удаленно монтировал ноутбук со своего настольного сервера. Первое монтирование происходит с IP-адресом A. Хотя перезагрузка ноутбука дает ему адрес B, мой рабочий стол продолжает записывать адрес A как адрес ноутбука. Я вижу это, когда проверяю IP-адрес, возвращенный mount команда и сравнение его с текущим адресом ноутбука.
- Я смог размонтировать используя
umount -l - Решением этой проблемы было - для меня - использовать фиксированный IP-адрес для ноутбука
У нас та же проблема, но, похоже, это происходит, только если корневая файловая система виртуальной машины - ext4. ext3 работает правильно. Я знаю, это звучит странно, но это может быть ошибка ядра, описанная в http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
Если это так, мы должны просто дождаться исправления ядра ИЛИ не устанавливать новый vm на основной машине. Установка его из временного Linux, запущенного как виртуальная машина, работает правильно, потому что машина перезагружается без перезагрузки основной машины.
Вы пробовали ext3? Если нет, попробуйте установить в ext3, вы можете преобразовать его в ext4 позже, если крайне важно использовать ext4 (и это описано в http://www.debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem)