Мне задавали этот вопрос в двух последовательных интервью, но после некоторого исследования и проверки с различными системными администраторами я не получил хорошего ответа. Мне интересно, может ли кто-нибудь помочь мне здесь.
На сервере недостаточно дискового пространства. Вы заметили очень большой файл журнала и решили, что его безопасно удалить. Вы удаляете файл, но диск все еще показывает, что он заполнен. Что вызвало бы это и как бы вы это исправили? И как вы узнаете, какой процесс записывает этот огромный файл журнала?
Ответы:
Это общий вопрос для интервью и ситуация, возникающая в различных производственных средах.
Записи каталога в файле были удалены, но процесс ведения журнала все еще выполняется. Пространство не будет возвращено операционной системой, пока все дескрипторы файлов не будут закрыты (например, процесс был убит) и все записи каталога удалены. Чтобы найти процесс записи в файл, вам нужно использовать
lsofкоманду.Другая часть вопроса иногда может быть: «Как очистить файл, в который выполняется запись, не прерывая процесс?» В идеале вы должны «обнулить» или «обрезать» файл журнала чем-то вроде
: > /var/log/logfileэтого вместо удаления файла.источник
fuser.no-clobberустановили, попробуйте:>| /var/log/logfiledfГоворят,duчто у вас недостаточно места, что вы почти ничего не используете. В чем причина, и почему два инструмента не согласны?»> /var/log/fileместа на диске все еще на 100%? Файл журнала кажется пустым ... но только после перезапуска программы, которая пишет в этот файл журнала, пространство восстанавливается. Есть ли способ восстановить дисковое пространство без перезапуска программы?Есть еще одна ссылка на файл (жесткая ссылка или дескриптор открытого файла). Удаление файла удаляет только запись каталога; данные файла и inode остаются до тех пор, пока не будет удалена последняя ссылка на него.
Для службы довольно распространено создание временного файла и его немедленное удаление, оставляя файл открытым. Это создает файл на диске, но гарантирует, что файл будет удален в случае ненормального завершения процесса, а также предотвращает случайное нажатие других процессов на файл. MySQL делает это, например, для всех своих временных таблиц на диске. Вредоносные программы часто используют аналогичную тактику, чтобы скрыть свои файлы.
В Linux вы можете легко получить доступ к этим удаленным файлам как
/proc/<pid>/fd/<filenumber>.источник
Я не являюсь системным администратором, но из того, что я собрал на Unix.SE, система Linux на самом деле не удалит файл (пометит пространство как свободное / многократно используемое) после того, как он отсоединится, пока все файловые дескрипторы, указывающие на них, не будут иметь был закрыт. Итак, чтобы ответить на первую часть, пространство еще не свободно, потому что процесс все еще читает его. Чтобы ответить на второй, вы можете увидеть, какой процесс использует файл с
lsof.источник
Один альтернативный ответ, помимо очевидного ответа с жесткой ссылкой / открытым файлом: этот файл является (очень) разреженным файлом, например,
/var/log/lastlogна RHEL, который на самом деле не занимал столько места. Удаление его оказало очень мало влияния, поэтому вам нужно посмотреть на следующий самый большой файл.источник
Если процесс записи файла является root, он запишет в зарезервированное файловое пространство суперпользователя. Файловая система имеет это пространство для поддержания работоспособности системы в случае, если пользовательская задача заполняет диск. Это пространство (по умолчанию 5%) невидимо для многих инструментов.
lsof может показать вам, какой процесс заблокировал файл, поэтому пишет в него.
источник
Помимо файла, открываемого процессом, второй случай - это когда у вас есть файловая система, которая поддерживает снимки типа
btrfsилиZFS.Например, вы делаете снимок с существующим огромным файлом журнала. Если вы удалите файл сейчас, вы удалите только дельту. И дельта удаляется только тогда, когда файл не используется.
Смотрите также:
/superuser/863588/how-to-delete-a-file-in-all-snapshots-on-a-btrfs-system
ZFS: удаление файлов из снимков?
Третий случай - когда у вас есть файловая система, которая поддерживает дедупликацию на уровне блоков, и большая часть файла идентична другому файлу. Я не ожидаю, что это произойдет с журналом, если у вас нет контейнера или виртуальной машины, которая отправляет журналы в контейнер системного журнала или виртуальную машину, которые совместно используют одну и ту же FS, так что содержимое журнала идентично.
источник