Назад | Перейти на главную страницу

Файл журнала отсутствует, как я могу его увидеть и что с ним произошло

Процесс, идентифицированный идентификатором процесса 2147, запущен, но его файл журнала нигде не найден. Файловая система - ext3, осталось 100 МБ. в процессе 2147 ничего не произошло. Команда lsof процесса 2147 показывает, что файл журнала все еще открыт.

а. Что могло произойти, чтобы файл журнала исчез?

б. Можете ли вы получить доступ к содержимому файла? Если да, то как?

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

Ad b) Вы не можете получить доступ к содержимому файла обычным способом, т.е. получить доступ к файловой системе обычным способом. Вам нужно будет начать доступ к данным под файловой системой, ища блоки, которые содержат данные блокнота. Если вы хотите попробовать это, то смонтируйте файловую систему, содержащую удаленный файл, только для чтения, как только вы уничтожите 2147, или вы рискуете перезаписать данные после выхода 2147, и блоки, содержащие его данные, будут помечены как неиспользуемые. Как именно найти нужные блоки данных? Извините, не могу вам помочь :(.

Как упоминалось в Повторное связывание удаленного файла, вы можете использовать /proc/<pid>/fd/N из lsof, чтобы получить копию дескриптора открытого файла и скопировать данные. Смотрите также Вернуть удаленные файлы с помощью lsof. Обратите внимание, что вы должны заставить исходный процесс прекратить запись в файловый дескриптор (например, остановить процесс). Кроме того, мне кажется, что вы хотите найти позицию 0 в дескрипторе файла (потребуется небольшой код), но я не упоминал об этом ни в одной статье, так что, возможно, я ошибаюсь.

В первой статье также упоминается несколько более рискованный метод использования debugfs также.

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

Если это происходит, будут некоторые свидетельства различий между выходными данными mount команда и /proc/2147/mounts. Вы можете (я предполагаю) получить доступ к перемонтированному файлу (большой мощь) через ссылки дескриптора файла в /proc/2147/fd.

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