Linux удалить файл занятый процессом

Удаление открытого файла

Кто-нибудь может знает, возможно ли удалить файл, в который идёт поток информации, т.е. файл открыт на запись другим преложением, а мне в какой-то определённый момент времени нужно его обнулить в Unix/Linux. провобoвал echo > file echo -n > file head -c 0 > file cat /dev/null > file раземр не сбрасывается!

4 ответа 4

Если файл не залочен (обычно это не делается), то его можно легко удалить. Однако, исчезновение файла из дерева файлов не будет означать его фактическое удаление. На самом деле, файл будет существовать до тех пор, пока приложение, выполняющее в него запись, не закроет его. В то же время, файл будет уже нельзя открыть. В таком промежуточном состоянии он будте продолжать занимать место на диске. Я не уверен, что это поведение воспроизводится на всех файловых системах, но под ext3 я точно наблюдал подобное.

PS: таким образом, ответ на ваш вопрос: всё-таки это плохая идея и стоит воздержаться от этого. Тем более, что это точно будет непереносимо на другие платформы (такие как Windows).

lsof на вход принимает имя файла, а раз файл удалён, то и файла нет. Следовательно, lsof скажет, что файл не найден. Но на самом деле, тело файла всё ещё существует, хотя ссылок на него из дерева файлов уже нет.

cy6ergn0m@cgmachine ~ $ cat - > ~/delete & [1] 22129 cy6ergn0m@cgmachine ~ $ [1] + suspended (tty input) cat - > ~/delete cy6ergn0m@cgmachine ~ $ /usr/sbin/lsof ~/delete COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME cat 21808 cy6ergn0m 1w REG 8,7 0 19128453 /home/cy6ergn0m/delete cy6ergn0m@cgmachine ~ $ rm -f ~/delete cy6ergn0m@cgmachine ~ $ /usr/sbin/lsof ~/delete lsof: status error on /home/cy6ergn0m/delete: No such file or directory lsof 4.83 latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/ latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man usage: [-?abhlnNoOPRtUvVX] [+|-c c] [+|-d s] [+D D] [+|-f[gG]] [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]] [-p s] [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names] Use the ``-h'' option to get more help information. 

Источник

Удаление открытого файла в Linux

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

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

Такие вопросы очень любят задавать на собеседованиях бывалые админы, а в интернете про ответы на них не написал только ленивый. Тем не менее кандидаты все также из раза в раз продолжают делать круглые глаза. Максимум, что от них можно услышать — это «Иноды. Я слышал про иноды, но больше про них ничего не знаю».

В этой статье раз и навсегда внесём ясность в этом вопросе.

Удаление открытого файла в Linux

Чтобы проверить как работает файловая система в Linux, проведем небольшой эксперимент.

Подготовка

Для проведения всех тестов нам необходима виртуальная машина с практически любым дистрибутивом Linux и дополнительный диск. Благо в век виртуализации это сделать проще простого. Для наглядности возьмем диск в пару гигабайт и заранее подготовим его (базовые операции с дисками рассмотрим в другой статье).

Представим, что вы впервые вошли по ssh на сервер, у вас рутовые права и ваша задача просто разобраться с дисковой подсистемой.

Свободное место и свободные иноды

Первое, что мы сделаем, это проверим диски всем знакомой командой df (лишние данные убраны из вывода):

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/test_disk_01-lv_test_01 1.5G 4.5M 1.4G 1% /mnt/data

Утилита отображает занятое на файловой системе место в блоках 1К. Этой информации в большинстве случаев хватает лишь для констатации факта о % свободного места и не стоит на этом останавливать диагностику.

Проблемы с записью новых файлов может вызвать также нехватка инодов (inodes), поэтому полезно будет их проверить той же командой, но с другим ключом:

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/mapper/test_disk_01-lv_test_01 98304 10 98294 1% /mnt/data

Используется 1% места на разделе. Запоминаем вывод команд, он нам понадобится для последующего анализа.

Создание файлов на диске

Далее создадим один большой файл на нашем диске. Сделать это проще всего утилитой dd, которая поставляется по умолчанию вместе с системой (предварительно создадим пару каталогов):

dd if=/dev/zero of=big/file.img bs=1G count=1

И ещё создадим 10 маленьких файлов, но другим способом:

Теперь снова смотрим два вывода df:

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/test_disk_01-lv_test_01 1.5G 1.1G 359M 75% /mnt/data

Как видно, теперь на диске занято 75%. А что с инодами?

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/mapper/test_disk_01-lv_test_01 98304 23 98281 1% /mnt/data

Количество инод изменилось на 13, хотя файлов мы создали всего 11.

Эксперимент с удалением открытого файла

Теперь посмотрим на ситуацию другой утилитой, которую также обязательно нужно использовать для диагностики. Речь о du:

Примечание: для изучения ключей наберите в консоли man du. Актуально также и для других утилит, рассматриваемых в статье.

Теперь сымитируем что-то похожее на блокировку файла (если будут предупреждения, соглашайтесь):

# less +F big/file.img >/dev/null &

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

После этого проверяем свободно место:

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/test_disk_01-lv_test_01 1.5G 1.1G 359M 75% /mnt/data

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/mapper/test_disk_01-lv_test_01 98304 23 98281 1% /mnt/data

В итоге место не освободилось, хотя файл, казалось бы, удален. Инодов используется столько же. Но может быть du покажет нам что-то другое:

Занято 8Кб. Ок, есть ещё одна утилита, которая лучше других объяснит что происходит, это lsof:

COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME

less 16483 root 3r REG 253,2 1073741824 11 /mnt/data/big/file.img (deleted)

Мы посмотрели все, что хотели, можно заканчивать.

Завершение эксперимента

Сворачиваем наш эксперимент — убиваем процесс, который мы ранее запустили в фоновом режиме:

Теперь снова проверяем свободное место:

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/test_disk_01-lv_test_01 1.5G 4.5M 1.4G 1% /mnt/data

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/mapper/test_disk_01-lv_test_01 98304 22 98282 1% /mnt/data

Большой файл удалился, место и иноды освободились. Смысла проверять вывод du нет, она покажет то же самое, что и в предыдущий раз.

Выводы

Что все же произошло? А произошло следующее: информация от du и df до удаления большого файла была очевидной и объяснений не требует. За исключением одного момента — почему файлов создали 11, а количество инодов увеличилось на 13? Тут все просто. Наверно все слышали выражение, что все в линуксе — файл 1? И каталог тоже, а их мы создали два.

Далее мы удалили файл, который открыт на чтение другим процессом. Команда rm удалила ссылку на файл, которую хранит объект каталога, но не смогла удалить файл физически с диска, поскольку файл был открыт на чтение другой программой.

Примечание: догадываетесь почему нельзя чистить логи путем простого удаления файлов без перезапуска приложения?

Хоть файл уже и не имел имени, но все ещё имел файловый дескриптор (= инод), к которому продолжала обращаться программа. Это было также хорошо заметно по выводу lsof — файл был помечен как удаленный. Как только программу остановили, файл освободился и система смогла завершить начатое — удалить файл и зависимые структуры данных на диске окончательно.

В показаниях утилиты du также нет ничего странного, ведь она считывает все перечисленные имена файлов в каталоге и оценивает их размер. Поскольку ссылку на имя большого файла удалили, du не смогла оценить его объем, зато это смогла сделать df, ведь она оценивает реальный занятый объем на диске в блоках без привязки к именам. Вот весь секрет.

Источник

Linux удалить файл занятый процессом

Пользуясь Linux, можно столкнуться с ситуацией, когда диск переполнен. Вы хотите освободить место на диске, но когда смотрите сколько занимают Ваши файлы, то оказывается что они занимают намного меньше пространства, чем занято на диске…

Выглядит это приблизительно так:

Файлы могут быть визуально удалены, но еще заняты какими-либо процессами. Поэтому их невозможно удалить по-настоящему с диска. Для нахождения таких файлов используйте команду:

Эти файлы почемены как “(deleted)”, но до сих пор находятся на диске.

Аналогично можно найти с помощью awk:

# find /proc/*/fd -ls 2> /dev/null | awk ‘/deleted/ ‘;

Мы увидим номер процесса и номер файлового дескриптора (fd), который нам и нужен.

Вручную можно “освободить” эти файлы так:

Где $PROC – номер процесса, а $FD – номер файлового дескриптора

# truncate -s 0 /proc/$PROC/fd/$FD

Чтобы пройтись по всем таким файлам разом, выполняем эту команду ( ВНИМАНИЕ! УБЕДИТЕСЬ В ТОМ, ЧТО ВЫ УВЕРЕНЫ В ТОМ, ЧТО ДЕЛАЕТЕ 🙂 ) :

# find /proc/*/fd -ls 2> /dev/null | awk ‘/deleted/ ‘ | xargs -p -n 1 truncate -s 0

Останется только подтверждать “усечение” кнопками y и Enter.

Вот теперь на диске есть столько свободного места, сколько должно быть:

Итак, в этой заметке мы рассмотрели как освободить место на диске от удаленных файлов (deleted) на Linux. Если Вам есть чем поделиться по этой теме, пишите в комментариях.

Источник

Почему в Linux приложение может удалить само себя, а в Windows нет?

В Windows, при попытке приложения удалить свой исполняемый файл, мы получим ошибку «файл занят процессом», а в Linux нет (по крайней мере консольная утилита, написанная на основе .NET Core, смогла снести все свои файлы не вызвав исключения).

Хотелось бы понять разность подходов.

Когда процесс открывает файл, он открывает дескриптор на определенную структуру данных. Эта структура содержит аттрибуты файла, права доступа, информацию о том, где хранятся данные файла и так далее.

В Win и *nix эта информация хранится в разных местах, и соответственно лок происходит по-разному.

В POSIX системах (unix, linux, etc.) информация о файле хранится iNode, а имя файла уже ссылается на iNode.

В Windows и DOS изначально информация о файле хранилась в структуре которая называется Directory Entry. В NTFS это немного изменилось, но подход они не меняли либо для обратной совместимости, либо не видели в этом нужды.

Собственно отсюда исторически и выросло, что в *nix при открытии файла дескриптор указывает на iNode, а само имя файла можно при этом свободно удалять, или делать несколько имен ссылающихся на одну iNode (hard link), которые можно произвольно менять, пока «файл открыт».

В Windows лочится непосредственно Directory Entry (или ее аналог в NTFS), следовательно его модифицировать в этот момент нельзя.

У обоих подходов есть свои плюсы и минусы и история. Пока нет предпосылок к тому, что на Windows захотят изменить подход.

Источник