Как я могу архивировать файловую систему proc?

Question

Я хотел бы сделать снимок всей моей файловой системы proc и сохранить его в архиве (или, в худшем случае, объединить все текстовые файлы в один текстовый файл).

Но когда я бегу:

tar -c /proc

Я получаю сегфо.

Какой лучший способ сделать это? Должен ли я настроить какой-нибудь рекурсивный обход каждого файла?

У меня есть только базовые * nix-утилиты, такие как bash, cat, ls, echo и т. Д. У меня нет ничего такого, как python, perl или java.

Answer 1

Файловая система linux / proc на самом деле является переменными ядра, выдавая себя за файловую систему.Там нет ничего, чтобы сохранить, таким образом, ничего для резервного копирования.Если система позволит вам, вы можете rm -rf /proc, и она волшебным образом появится при следующей перезагрузке.

Файловая система / dev имеет настоящие i-узлы, и они могут быть скопированы.За исключением того, что у них нет содержимого, только старший и младший номер, разрешения и имя.Инструменты, которые выполняют резервное копирование специальных файлов устройства, записывают только эти параметры и никогда не пытаются открыть (2) устройство.Тем не менее, поскольку старшие и младшие номера устройства имеют смысл только в той системе, для которой они созданы, резервное копирование их не имеет особых оснований.

Причина, по которой попытка переархивировать псевдофайловую систему / proc вызывает tarк segfault - потому что / proc имеет забавное поведение файла: такие вещи, как псевдофайл только для записи, могут иметь разрешения на чтение, но возвращают сообщение об ошибке, если программа пытается открыть (2) его для резервного копирования.Это наверняка приведет наворотливый tar для получения привередливости.

Добавлено в ответ на комментарий

Меня не удивляет, что tar имел проблемы с чтением / proc / kmsg, потому что у него есть некоторые забавные свойства:

# strace cat /proc/kmsg
execve("/bin/cat", ["cat", "kmsg"],
open("kmsg", O_RDONLY|O_LARGEFILE)      = 3
// ok, no problem opening the file for reading
fstat64(3, { st_mode=S_IFREG|0400,  st_size=0,
// looks like a normal file of zero length
// but cat does not pay attention to st_size so it just
// does a blocking read
read(3, "<4>[103128.156051] ata2.00: qc t"..., 32768) = 461
write(1, "<4>[103128.156051] ata2.00: qc t"..., 461) = 461
// ...forever...
read(3, "<6>[103158.228444] ata2.00: conf"..., 32768) = 48
write(1, "<6>[103158.228444] ata2.00: conf"..., 48) = 48
+++ killed by SIGINT +++

Поскольку / proc / kmsg - это текущий список сообщений ядра по мере их появления, он никогда не возвращает 0 (EOF), он просто продолжается до тех пор, пока мне не надоест и не нажму ^ C.

Интересно, что у моего tar нет проблем с / proc / kmsg:

$ tar --version
tar (GNU tar) 1.22
# tar cf /tmp/junk.tar /proc/kmsg
$ tar tvf /tmp/junk.tar
-r-------- root/root         0 2010-09-01 14:41 proc/kmsg

, и если вы посмотрите на вывод strace, GNU tar 1.22 увидел, что st_length == 0, и даже не удосужился открыть файл.для чтения, поскольку там ничего не было.

Я могу представить, что ваш tar увидел, что длина равна 0, выделил столько (ни одного) пространства, используя malloc (3), который должным образом вернул указатель на нольдлина буфера.Ваш tar прочитал из / proc / kmsg, получил чтение ненулевой длины и попытался сохранить его в буфере нулевой длины и получил нарушение сегментации.

Это всего лишь одна крысиная дыра, которая ожидает tar в/ Proc.Сколько еще там?Не знаю.Будут ли они вести себя одинаково?Возможно нет.Какие из ~ 1000 или около того файлов, которые не являются /proc/<pid> псевдо-файлами, будут иметь странную семантику?Не знаю.

Но, пожалуй, самый интересный вопрос: какой смысл вы бы имели в / proc / sys / vm / lowmem_reserve_ratio, он будет другим на следующей неделе, и сможете ли вы чему-нибудь научиться из этого различия?

Answer 2

Хотя принятый ответ имеет большой смысл, если вы хотите спорить о смысле делать что-то подобное, тем не менее, есть ответ, который работает. Вот скрипт для дублирования полной файловой системы / proc в / tmp / proc. Это может быть затем смолено и разархивировано. Я использовал это, чтобы сохранить память о настройках и возможностях (память, bogomips, процессы по умолчанию и т. Д.) Моего верного старого файлового сервера, прежде чем заменить его на новый.

cd /
mkdir /tmp/proc
find /proc -type f | while read F ; do
   D=/tmp/$(dirname $F)
   test -d $D || mkdir -p $D
   test -f /tmp/$F || sudo cat $F > /tmp/$F
done

Примечания: Разрешения не сохраняются, так как я должен использовать cat вместо cp. cp -a /proc /proccopy не работает, так как он также падает на "kcore". mc (Midnight Commander) преуспевает в создании копии / proc, которую вы можете затем использовать tar и gzip, но вам нужно отклонить тысячи ошибок «Cannot read file XYZ», и это также вылетает на «kcore» с ошибкой Bus. *

Answer 3

Простой ответ:

ls -Rd /proc/* > proc.lst 
foreach item (<proc.lst>)
  echo "proc_file:$item"
  if (-f $item) cat $item
end

По поводу консультативного протокола сайта:

"Но избегайте ... Делайте заявления, основанные на мнении ..."

(ИМХО ... основываясь на многолетнем опыте) Не нужно много воображения, чтобы придумать веские причины для того, чтобы в данный момент сделать снимок выбранных элементов / proc / * и хранить или отправлять куда-нибудь. Поэтому я бы поставил под сомнение полезность «ответа», такого как:

Файловая система linux / proc на самом деле является переменными ядра, выдавая себя за файловую систему. Там нет ничего, чтобы сохранить, таким образом, ничего для резервного копирования. Если система позволит вам, вы можете запустить rm -rf / proc, и он волшебным образом появится при следующей перезагрузке.

... на том основании, что он не отвечает на вопрос, делает ложное утверждение и содержит безвозмездную информацию, не относящуюся к вопросу.