如何压缩 proc 文件系统？

发布于 2024-09-17 06:35:43 字数 262 浏览 2 评论 0原文

我想拍摄整个 proc 文件系统的快照，并将其保存在 tarball 中（或者在最坏的情况下将所有文本文件连接到一个文本文件中）。

但是当我运行时：

tar -c /proc

我遇到了段错误。

最好的方法是什么？我应该设置某种递归遍历每个文件吗？

我只有基本的 *nix 实用程序，例如 bash、cat、ls、echo 等。我没有任何像 python、perl 或 java 这样的奇特东西。

原文

I would like to take a snapshot of my entire proc file system, and save it in a tarball (or in the worst case concatenate all of the text files together into a single text file).

But when I run:

tar -c /proc

I get a segfault.

What's the best way to do this? Should I set up some kind of recursive walk through each file?

I only have the basic *nix utilities, such as bash, cat, ls, echo, etc. I don't have anything fancy like python or perl or java.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

寻梦旅人 2024-09-24 06:35:45

linux /proc 文件系统实际上是伪装成文件系统的内核变量。没有什么可以保存，因此也没有什么可以备份。如果系统允许，您可以rm -rf /proc，它会在下次重新启动时神奇地重新出现。

/dev 文件系统有真正的 i 节点并且可以备份。但它们没有内容，只有主编号、次编号、权限和名称。备份特殊设备文件的工具仅记录这些参数，而不会尝试打开(2) 设备。然而，由于设备的主设备号和次设备号仅在其构建的精确系统上才有意义，因此没有理由备份它们。

尝试 tar /proc 伪文件系统导致 tar 出现段错误的原因是 /proc 有有趣的文件行为：诸如只写伪文件之类的东西可能看起来具有读取权限，但如果程序尝试这样做，则返回错误指示打开(2)它进行备份。这肯定会让天真的焦油变得吹毛求疵。

针对评论添加的

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 读取，获得非零长度读取，并尝试将其存储在零长度缓冲区中，并遇到分段冲突。

这只是 /proc 中等待 tar 的一个老鼠洞。还有多少个？不知道。他们的行为会相同吗？可能不会。大约 1000 个左右的文件中，哪些不是 /proc/ psuedo-files 将具有奇怪的语义？不知道。

但也许最有说服力的问题是：您对 /proc/sys/vm/lowmem_reserve_ratio 有什么意义？下周会有所不同吗？您能从这种差异中学到什么吗？

The linux /proc filesystem is actually kernel variables pretending to be a filesystem. There is nothing to save thus nothing to backup. If the system let you, you could rm -rf /proc and it would magically reappear upon the next reboot.

The /dev file system has real i-nodes and they can be backed up. Except they have no contents, just a major and minor number, permissions, and a name. Tools that do backup special device files only record those parameters and never try to open(2) the device. However, since the device major and minor numbers are only meaningful on the precise system they are built for, there is little cause for backing them up.

The reason that trying to tar the /proc pseudo-filesystem causes tar to segfault is because /proc has funny file behavior: things like a write-only pseudo-file may appear to have read permissions, but return an error indication if a program tries to open(2) it for backup. That's sure to drive a naïve tar to get persnickety.

Added in response to comment

It doesn't surprise me that tar had problems reading /proc/kmsg because it has some funny properties:

# 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 +++

Since /proc/kmsg is a running list of kernel messages as they happen, it never returns 0 (EOF) it just keeps going until I get bored and press ^C.

Interestingly, my tar has no trouble with /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

and if you look at the strace output, GNU tar 1.22 saw that st_length == 0 and didn't even bother opening the file for reading, since there wasn't anything there.

I can imagine that your tar saw the length was 0, allocated that much (none) space using malloc(3) which dutifully handed back a pointer to a zero length buffer. Your tar read from /proc/kmsg, got a non-zero length read, and tried to store it in the zero length buffer and got a segmentation violation.

That is but one rat-hole that awaits tar in /proc. How many more are there? Dunno. Will they behave identically? Probably not. Which of the ~1000 or so files which aren't /proc/<pid> psuedo-files are going to have weird semantics? Dunno.

But perhaps the most telling question: What sense would you make of /proc/sys/vm/lowmem_reserve_ratio, will it be different next week, and will you be able to learn anything from that difference?

回复收藏 0 原文

浪荡不羁 2024-09-24 06:35:45

虽然如果您想争论做这样的事情的意义，那么接受的答案很有意义，但仍然有一个有效的答案。这是一个将完整的 /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，但是您必须消除数千个“无法读取文件 XYZ”错误，并且它也会因总线错误而在“kcore”上崩溃。

While the accepted answer makes a lot of sense if you want to argue the sense of doing something like this, nevertheless there is an answer that works. Here's a script to duplicate the complete /proc file system into /tmp/proc. This can then be tarred and gzipped. I used this to keep a memory of the setup and capabilities (memory, bogomips, default processes, etc.) of my trusty old file server before I replaced it with a new one.

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

Notes:
Permissions are not preserved since I have to use cat instead of cp.
cp -a /proc /proccopy doesn't work since it crashes on "kcore" as well. mc (Midnight Commander) succeeds in creating a copy of /proc which you can then tar and gzip, but you have to dismiss thousands of "Cannot read file XYZ" errors and it too crashes on 'kcore' with a Bus Error.

回复收藏 0 原文

决绝 2024-09-24 06:35:45

一个简单的答案：

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 ，它会在下次重新启动时神奇地重新出现。

...因为它没有回答问题，做出了错误的断言，并且包含无缘无故的内容与问题无关的信息。

A simple answer:

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

Apropos the site advisory protocol:

"But avoid ... Making statements based on opinion..."

(IMHO...based on quite a few years experience) It doesn't require much imagination to think of some good reasons for, at a given point in time, taking a snapshot of selected elements of /proc/* and storing it, or sending it somewhere. Therefore, I would question the usefulness of an 'answer' such as:

The linux /proc filesystem is actually kernel variables pretending to be a filesystem. There is nothing to save thus nothing to backup. If the system let you, you could rm -rf /proc and it would magically reappear upon the next reboot.

...on the grounds that it doesn't answer the question, makes a false assertion, and contains gratuitous information irrelevant to the question.

回复收藏 0 原文

~没有更多了~