Как программа журнала может продолжить работу с удаленным файлом?

Из Unix Power Tools, 3-е издание : вместо удаления файла, Empty It section:

Если активный процесс имеет открытый файл (не редкость для файлов журналов), удаление файла и создание нового не повлияет на программу ведения журнала; эти сообщения будут просто продолжать работу с файлом, который больше не связан . Опорожнение файла не нарушает связь, и поэтому он очищает файл, не затрагивая программу ведения журнала.

( акцент мой )

Я не совсем понимаю, почему программа журнала будет продолжать регистрироваться в файле удаления? Это потому, что запись дескриптора файла не удаляется из таблицы процессов?

3 Solutions collect form web for “Как программа журнала может продолжить работу с удаленным файлом?”

Когда вы удаляете файл, вы действительно удаляете ссылку на файл (в индексный дескриптор). Если у кого-то уже открыт этот файл, они могут сохранить дескриптор файла, который у них есть. Файл остается на диске, занимая место, и его можно записать и прочитать, если у вас есть доступ к нему.

Функция unlink определяется с помощью этого поведения POSIX:

Когда количество ссылок на файл становится равным 0, и процесс не открывается, пространство, занимаемое файлом, должно быть освобождено, и файл больше не будет доступен. Если один или несколько процессов открывают файл при удалении последней ссылки, ссылка должна быть удалена до возврата функции unlink (), но удаление содержимого файла должно быть отложено до тех пор, пока все ссылки на файл не будут закрыты .

Этот совет из-за этого поведения. Демон откроет файл и не заметит, что он был удален (если только он не контролировал его, что является необычным). Он будет вести беспечную запись в существующий файловый дескриптор, который он имеет: вы будете продолжать занимать больше места на диске, но вы не сможете увидеть ни одного из сообщений, которые он пишет, так что вы действительно в худшем обоих миров. Если вы усекаете файл до нулевой длины, вместо этого пространство сразу освобождается, и все новые сообщения будут добавляться в новый конец файла, где вы можете их увидеть.

В конце концов, когда демон завершает или close файл , пространство будет освобождено. Никто не может открывать файл в среднем (за исключением системных рефлексивных интерфейсов, таких как Linux /proc/x/fd/... ). Также гарантируется, что:

Если количество ссылок на файл равно 0, когда все дескрипторы файлов, связанные с файлом, закрыты, пространство, занимаемое файлом, должно быть освобождено, и файл больше не будет доступен.

Таким образом, вы не теряете свое место на диске постоянно, но ничего не получаете, удаляя файл и теряете доступ к новым сообщениям.

В точку.

Файлы являются трехчастными.

  • Содержимое, то есть плоский массив байтов, записанный где-то на диске или сгенерированный «на лету».
  • Индексный узел или индекс inode для краткости, который является структурой данных, заполненной и используемой ядром. Он содержит все метаданные (размер, разрешение и т. Д.) О файле, а также указывает на местоположение содержимого файла.
  • Одна или несколько записей каталога , которые являются местоположениями, управляются как пути, например /home/user/personal_file , которые действуют как дескрипторы, через которые вы можете использовать файл, изменять его содержимое, изменять его метаданные и т. Д.

Когда вы открываете файл, вы указываете путь к операционной системе и возвращает дескриптор непосредственно в индексный дескриптор. С помощью этого дескриптора, называемого файловым дескриптором, вы можете управлять файлом по своему усмотрению (или, по крайней мере, разрешенным ОС).

Вы никогда не сможете напрямую удалить inode, вам нужно указать путь к ОС, чтобы потребовать удаления. Поэтому, когда вы хотите удалить файл, вы удаляете только запись в каталоге. Если файл имеет другие записи в каталоге, он будет оставаться доступным, и даже если он его не имеет, его индекс не будет удален, пока на нем будут указатели файлов. @ Ответ MichaelHomer более технический и более подробный в этой конкретной теме.

Остальные 2 ответа хорошо объясняют проблему – файл не получает «удален» до тех пор, пока все ссылки на него каталогов и все открытые дескрипторы файла к нему не исчезнут.

Чтобы этого избежать, это хорошая привычка использовать

 > /var/log/bigfile 

вместо

 rm -f /var/log/bigfile 

так как это просто сбрасывает содержимое на 0 байтов, а не удаляет его, и вы все равно можете видеть, что написано на нем.

Если вы удалили файл и находитесь в Linux, где у вас есть файловая система / proc / fd, вы все равно можете использовать

 > /proc/12345/fd/3 

до нуля содержимого файла (при условии, что 12345 – ваш идентификатор процесса, а 3 – номер fd большого файла). Это может быть спасателем жизни, если ваш диск работает полностью, и по какой-то причине вы не можете убить процесс, который записывает ваш файл журнала.

  • display sco unix 5.0.6 использование samba
  • Как узнать, кто находится на другом конце псевдотерминального устройства?
  • Прочтите «/ proc», чтобы узнать, открыл ли процесс порт
  • Удаление файла по сравнению с переписыванием и ссылка на / proc / pid / fd
  • Возьмите стандартный ввод / вывод запущенного процесса под FreeBSD / macOS
  • Как перечислить дескрипторы открытых файлов (и файлы, на которые они ссылаются) в моей текущей сессии bash
  • Определите процесс, который все еще использует файл в ленивой немонтированной файловой системе
  • Отображаются ли все открытые файлы в формате lsof?
  • Как настроить сеанс OpenBox для открытия файлов с помощью типа mime?
  • Что такое сетевой сокет?
  • Ошибка `ls` при удалении каталога
  • Предотвращение активного удаления файлов в файловой системе NFS
  • Linux и Unix - лучшая ОС в мире.