Comments 32
Проверили бы через текстовый редактор написанный материал на наличие хотя бы орфографических ошибок. Материал хороший, а читать невозможно.
-9
Написали бы ещё поподробнее — что вообще происходит с открытым файлом при его удалении, где (на диске или в памяти) всё это время хранится копия удалённого файла, работает ли такой метод с большими файлами?
+5
Файл лежит где лежал, пока он открыт хоть одним процессом. Как только все процессы закроют файл или завершатся, место на диске помечается как свободное и может быть перезаписано другим файлом.
+4
При открытии файла увеличивается счётчик жёстких ссылок, при закрытии — уменьшается. Если счётчик = 0, то место, занимавшееся файло, считается пустым.
Так что, возможно, прокатит метод не только «cp /proc/pid/fd/n blah», а и «ln ....» (а может и нет, ведь точки монтирования у /proc и остального разные).
Так что, возможно, прокатит метод не только «cp /proc/pid/fd/n blah», а и «ln ....» (а может и нет, ведь точки монтирования у /proc и остального разные).
+1
Вместо grep правильнее передавать путь самому lsof:
datacompboy@nuuzerpogodible:~$ tail 123 -f & 123 datacompboy@nuuzerpogodible:~$ lsof /home/datacompboy/123 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME tail 29434 datacompboy 3r REG 8,5 4 1765588 /home/datacompboy/123 datacompboy@nuuzerpogodible:~$ lsof -p 29434 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME tail 29434 datacompboy cwd DIR 8,5 14400 4521 /home/datacompboy tail 29434 datacompboy rtd DIR 8,5 1008 2 / tail 29434 datacompboy txt REG 8,5 64232 733586 /usr/bin/tail tail 29434 datacompboy mem REG 8,5 2855040 1245149 /usr/lib/locale/locale-archive tail 29434 datacompboy mem REG 8,5 1742520 1463374 /lib/x86_64-linux-gnu/libc-2.17.so tail 29434 datacompboy mem REG 8,5 145160 1463324 /lib/x86_64-linux-gnu/ld-2.17.so tail 29434 datacompboy 0u CHR 136,0 0t0 3 /dev/pts/0 tail 29434 datacompboy 1u CHR 136,0 0t0 3 /dev/pts/0 tail 29434 datacompboy 2u CHR 136,0 0t0 3 /dev/pts/0 tail 29434 datacompboy 3r REG 8,5 4 1765588 /home/datacompboy/123 tail 29434 datacompboy 4r 0000 0,9 0 3546 anon_inode
+6
> Номер открытого файла
Понимаю, что слово file descriptor сложновато понятно перевести на русский, но «номер файла» — не корректно. Это вроде и не номер и кроме файла дескриптор может ссылаться, например, на сокет. Таким образом не знающие могут подумать, например, что речь идет про inode.
Я бы исправил.
Ну и вцелом статья коротковата, конечно. Хорошо бы расписали что к чему поподробнее — про вывод lsof, про freebsd, где /proc, кстати, отсутствует по дефолту. Что такое эти «номера файлов», что такое /proc…
Понимаю, что слово file descriptor сложновато понятно перевести на русский, но «номер файла» — не корректно. Это вроде и не номер и кроме файла дескриптор может ссылаться, например, на сокет. Таким образом не знающие могут подумать, например, что речь идет про inode.
Я бы исправил.
Ну и вцелом статья коротковата, конечно. Хорошо бы расписали что к чему поподробнее — про вывод lsof, про freebsd, где /proc, кстати, отсутствует по дефолту. Что такое эти «номера файлов», что такое /proc…
+3
Во FreeBSD нет procfs (в GENERIC) и /proc. И поэтому данный метод восстановления для нее не подходит.
P.S. ZFS и снапшоты помогут в восстановлении.
P.S. ZFS и снапшоты помогут в восстановлении.
0
UFO just landed and posted this here
Программы могут один раз прочитать конфиг и не держать его открытым. Так что не всегда поможет.
+5
Сам исполняемый файл кстати тоже так можно восстановить, из /proc//exe.
+2
А зачем вообще lsof? cd /proc/pid/fd, ls -lia покажет и список открытых процессом файлов, и позволит прямо оттуда скопировать их по местам.
0
Наверно, чтобы посмотреть оригинальные названия файлов, что нужно, что нет, что удалено, что нет(чтобы все было в одном месте). То есть просто ради удобства, могу предположить…
0
Раз в год стабильно появляется статья человека, открывшего этот способ. Все конечно хорошо, но…
+2
Ну давайте я добавлю «пользы» примером из жизни =)
На одном из серверов столкнулись с проблемами свободного места на диске. При этом анализ директорий du'ом не показывал ничего криминального, хотя мы не досчитались под сотню гигов что-ли. Потом выяснилось, что один из долгоиграющих процессов открыл дескриптор большого файла (лога чтоли, не помню, не суть) и писал в него. Запись в каталоге о файле удалили, но пока дескриптор открыт — ОС позволяет спокойно с ним работать. Утилита du при этом покажет «не правильный» размер каталога, с учетом «удаленного» файла.
А нашли это как раз с помощью
lsof |grep deleted
Забавно. Всё не хватает времени поэкспериментировать, как поведут себя различные механизмы квот на дисковое место. Если не правильно учитывать такие вот удаленные файлы, то можно запросто забить диск, не смотря на квоту =) Ни кто не хочет исследовать?
На одном из серверов столкнулись с проблемами свободного места на диске. При этом анализ директорий du'ом не показывал ничего криминального, хотя мы не досчитались под сотню гигов что-ли. Потом выяснилось, что один из долгоиграющих процессов открыл дескриптор большого файла (лога чтоли, не помню, не суть) и писал в него. Запись в каталоге о файле удалили, но пока дескриптор открыт — ОС позволяет спокойно с ним работать. Утилита du при этом покажет «не правильный» размер каталога, с учетом «удаленного» файла.
А нашли это как раз с помощью
lsof |grep deleted
Забавно. Всё не хватает времени поэкспериментировать, как поведут себя различные механизмы квот на дисковое место. Если не правильно учитывать такие вот удаленные файлы, то можно запросто забить диск, не смотря на квоту =) Ни кто не хочет исследовать?
0
Потом выяснилось, что один из долгоиграющих процессов открыл дескриптор большого файла (лога чтоли, не помню, не суть) и писал в него. Запись в каталоге о файле удалили
за такое надо бить больно по рукам )) причем всем: и тем, кто писал код… и тем, кто так удаляет :)
0
Р., я не помню подробностей, но там не специально так сделали. Лог должен был крутиться, но что-то помешало. Поятно, что так нельзя, не первый год замужем =)
~ $ uptime
13:03:23 up 1016 days,
~ $ uptime
13:03:23 up 1016 days,
0
какие проблемы? HUP посылаем процессу, он переоткрывает файлы.
вот если он так не делает — вот тогда да, тогда по рукам.
вот если он так не делает — вот тогда да, тогда по рукам.
0
Я примерно так сохраняю видеоролики из онлайна (неважно — ютуб, рутуб, вимео — всё работает).
Просто открываю ролик, жду когда весь скачается — и ищу его fd-шках у процесса /usr/lib/firefox/plugin-container
(можно и lsof-ом, но мне быстрее прямо в mc перелистать все ссылки в папке /proc//fd). Ролик обычно находится в удалённом файле в /tmp (т.е. по окончании просмотра он окончательно канет в небытие). Дальше F5 и отметка галки «разыменовывать ссылки» — и ролик у меня. Можно либо добавить расширение .flv, либо открыть avidemux-ом и пересохранить в «правильный» контейнер.
Просто открываю ролик, жду когда весь скачается — и ищу его fd-шках у процесса /usr/lib/firefox/plugin-container
(можно и lsof-ом, но мне быстрее прямо в mc перелистать все ссылки в папке /proc//fd). Ролик обычно находится в удалённом файле в /tmp (т.е. по окончании просмотра он окончательно канет в небытие). Дальше F5 и отметка галки «разыменовывать ссылки» — и ролик у меня. Можно либо добавить расширение .flv, либо открыть avidemux-ом и пересохранить в «правильный» контейнер.
+3
UFO just landed and posted this here
Sign up to leave a comment.
Восстановление открытых файлов но удаленных c файловой системы linux