Не может размонтироваться цикл поддержал файл, но нет никаких открытых файлов?
По моему опыту, logrotate является большим. Это очень гибко, и работает хорошо с большей частью программного обеспечения.
Однако существуют некоторые проблемы с ним, и поскольку cronolog является, прежде всего, средством вращения блога, я запишу свой опыт с logrotate + апач, который был проблематичен:
При вращении журналов мы должны уведомить апача, что журнал поворачивается, как, даже если logrotate переименует access.log к доступу log.1, то апач продолжит писать в доступ log.1, как он пишет в inode и переименовывает файл, не влияет на inode число.
На травлении debian (и вероятно много других дистрибутивов), logrotate используется для вращения апачских журналов. Теперь, у апача есть корректный перезапуск, который советует апачским дочерним процессам выходить, после того как они заканчивают служить существующим соединениям, апач затем перечитывает, это - конфигурация, новые дочерние процессы икры, которые начинают писать в новый файл журнала (В случае, если предыдущий был повернут).
Это походит на отличное решение, однако корректный перезапуск не всегда работает в определенных условиях (как большая нагрузка), таким образом, debian разработчики решили использовать апачский перезапуск вместо корректного перезапуска в апачской logrotate конфигурации. Unfortunetly это заставляет все соединения быть отброшенными сразу, который очень плох для в большой степени загруженных сайтов. Кроме того, апачский перезапуск может также вызвать проблемы как апачская остановка и не запуск (также в определенных ситуациях с загрузкой), видеть ссылки ниже ошибки для деталей.
Нижняя строка, logrotate является большим, но может привести к определенным вопросам для определенных программ. У меня нет большого опыта с cronolog, но поскольку он пишет журналы через канал, он не требует никаких апачских перезагрузок, когда он поворачивает файлы журнала, который в основном решает все, что описано выше.
Связанный logrotate/apache debian ошибки:
Я полагаю, что это - то, для чего термофиксатор. А именно, fuser -km /path/to/mount/point - обратите внимание что -k флаг уничтожает процессы с файлами, открытыми в этой файловой системе. Можно опустить этот флаг для наблюдения списка сначала.
-
1- k, также уничтожают все процессы с помощью него. – Kyle Brandt 26 August 2009 в 20:07
-
2хорошо, если Вы хотите размонтировать его, that' s, что необходимо сделать, правильно? Надо надеяться, люди don' t просто вырезанные и вставленные команды они видят в Интернете (и выполните их как корень и измените поддельный путь к каталогу на один that' s реальный...) – chris 26 August 2009 в 20:44
В Вашем вопросе Вы записали grep pathofimagefile. Вы попробовали grep pathofmountpoint?
Также проверьте, что никакой процесс, работающий на Вашей машине, не имеет Вашу точку монтирования (или подкаталог его) набор как его текущий рабочий каталог.
sudo ls -l /proc/*/cwd | grep pathofmountpoint даст Вам те числа процесса.
Удостоверьтесь, что у Вас нет открытой оболочки, это находится в смонтированном каталоге. Я никогда не надеялся видеть, показывает ли это в lsof или нет. Также, когда выполнение Вашего lsof пытается хватать на точке монтирования не сам файл изображения.
выполненный pwd ... Ваш терминал, все еще находящийся в pathofimagefile? Раз так переместитесь из pathofimagefile и затем повторно выполнитесь umount.
-
1Я думал об этом, и не, it' s нет. I' ve, застрявший с этим прежде. Но это обнаружилось бы в lsof – Rory 27 August 2009 в 00:09
-
1
У меня была та же проблема. Каталог был не только смонтирован с -o loop, но это экспортировалось в NFS с помощью exportfs команда. fuser и lsof оба сказали, что устройство не использовалось. Кроме того, exportfs -u не имел никаких жалоб. Однако NFS все еще показывал устройство в/proc/fs/nfs/exports. Я перезапустил nfs и получил это:
Shutting down NFS mountd: [ OK ] Shutting down NFS daemon: [ OK ] Shutting down NFS services: [FAILED] Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS daemon: [ OK ] Starting NFS mountd: [ OK ]
Затем я мог umount устройства. К сожалению, довольно трудно воспроизвести. Возможно, кто-то может дать больше понимания.
Вау, это действительно старое, но чтобы помочь тем, кто обнаружит это в будущем, вот что я обнаружил - У меня были вложенные средства передвижения. То есть я смонтировал образ корневой файловой системы с устройством обратной связи на / mnt. Под этой точкой монтирования я затем смонтировал файловые системы proc и sysfs, смонтированные в / mnt / proc и / mnt / sys. Позже я забыл о файловых системах proc и sysfs, когда пытался размонтировать образ файловой системы.
# mount -o loop rootfs_disk.img /mnt
# mount proc /mnt/proc -t proc
# mount sysfs /mnt/sys -t sysfs
# # ... ages pass
# umount rootfs_disk.img
umount: /mnt: device is busy.
# umount /mnt
umount: /mnt: device is busy.
- Ной Спурриер
У меня только что возникла та же проблема: umount не размонтирует мое устройство петли. Как ни странно, ни lsof, ни fuser не смогли найти какой-либо процесс, использующий эту точку монтирования. lsof нашел только поток ядра [loop0], я попытался убить его (даже с -9), но безуспешно.
Что меня действительно удивило, так это то, что после нескольких минут ожидания (после попытки umount -f / mnt и т. д. . - не сработало), я попробовал еще раз, и вуаля, теперь это сработало ?!
Я не уверен, но, может быть, само ядро какое-то время не могло освободить loop0-thread, но потом оно мог закрыть это? Кто знает ...
Итак, суть в следующем: попробуйте этот umount снова и снова, через определенное время вам может повезти: -)