多年来,我一直有一个模糊的想法,即/ proc是Linux内核公开其内部结构的一种方式,并且我可以在那里寻找东西。
然后我学到了这一点:
直到!如果您不小心删除了一个仍处于打开状态的文件,则可以使用cat / proc / $ pid / fd / $ file_descriptor恢复该文件。太简单!
突然间,它/proc
变成了一个神奇的独角兽!我可以用它来恢复我的文件吗?★★惊人的★★。
让我们解释一下为什么行得通。进程打开文件(包括套接字)时,它将获取该文件的文件描述符,该描述符是一个从0开始的数字。
0、1和2始终是进程的stdin,stdout和stderr。例如,如果我查看具有的Google Chrome进程的文件描述符,则会看到:
$ ls / proc / 4076 / fd 0 10 12 14 16 18 2 21 23 26 28 3 31 34 36 38 4 41 43 5 6 72 8 1 11 13 15 17 19 20 22 25 27 29 30 32 35 37 39 40 42 44 53 7 74 9
那真是不透明!让我们仔细看看。
$ ls -l / proc / 4076 / fd / {0,1,2} lr-x ------ 1 bork bork 64 Mar 22 22:38 / proc / 4076 / fd / 0-> / dev / null l-wx ------ 1 bork bork 64 Mar 22 22:38 / proc / 4076 / fd / 1-> / dev / null l-wx ------ 1 bork bork 64 Mar 22 22:38 / proc / 4076 / fd / 2-> /home/bork/.xsession-errors
整洁的数字0、1和2只是符号链接!Chrome似乎没有任何stdin或stdout,这很有意义,但stderr是/home/bork/.xsession-errors
。我不知道!事实证明,这也是找出未启动进程将其输出重定向到何处的好方法。
我的程序还可以在其他地方重定向其stderr?让我们来看看!我看了看所有东西的stderr,awk只取出文件,然后跑去 uniq
获取计数。
$ ls -l / proc / * / fd / 2 | awk'{print $ 11}'| 排序| uniq -c 42 / dev /空 2 / dev / pts / 0 1 / dev / pts / 1 3 / dev / pts / 2 2 / dev / pts / 3 2 / dev / pts / 4 5 / dev / pts / 5 1 / dev / pts / 725 /home/bork/.xsession-errors
因此,大多数情况是/ dev / null,其中一些运行在终端(/dev/pts/*
)上,其余运行在上~/.xsession-errors
。这里没有什么大的惊喜。
之所以可行,是因为当您一次又一次地打开一个循环中的不同文件时,它通常会以相同的文件描述符结尾。您还可以通过运行strace -etrace=open -p$TARSNAP_PID
查看Tarsnap打开的文件来执行相同的操作。
好的,现在我们知道可以使用/ proc来了解进程的文件了!还有什么?
如果查看该文件/proc/$pid/status
,则可以找到有关您的过程的各种信息!您可以在任何过程中查看它。
这是该文件中内容的一个示例:
名称:铬 群组:4 20 24 27 30 46 104 109 124 1000 VmPeak:853984 kB Vm大小:670392 kB VmData:323264 kB VmExe:96100 kB 线程数:3 Cpus_allowed_list:0-7
因此,我们可以看到有关内存,其名称,其组,其线程以及允许在哪些CPU上运行的信息。
可是等等!我们可以通过找到许多此类信息ps aux
。怎么ps
做?让我们找出答案!
$ strace -f -etrace =打开ps辅助 ... 打开(“ / proc / 30219 / stat”,O_RDONLY)= 6 open(“ / proc / 30219 / status”,O_RDONLY)= 6 打开(“ / proc / 30219 / cmdline”,O_RDONLY)= 6 ...
因此ps
从中获取信息/proc
!整齐。