在Linux中追查进程信息

领导：小鱼啊，你看下这两个容器，明明一样的，怎么就一个能运行指令，另一个一直超时呢？

煎鱼收到了任务后，就立刻进行问题排查，渐渐地查到了原因。

首先，命令发起程序和容器之间的关系如下：

命令发起程序是在容器外的，通过一个库把需要执行的命令推送到容器内，而容器内有一个worker程序收到这个命令推送后，就在容器内执行所要执行的命令。（容器通信自行了解）

一顿ps -ef操作对比后。

煎鱼：领导，你看，这两个容器虽然都正常启动了，但是其中容器A的worker是正常运行的，而容器B的worker已经没有了，明显是挂了或者根本没有启动。

领导：啊？可是我并不知道这个怎么搞啊。那再启动一下不好吗？

煎鱼：可是我并不知道这个程序的目录是在哪里的。

领导：小鱼啊，这不是有另一个正常的容器嘛，你查一下容器的worker是在哪跑起来的不行吗？

煎鱼：好有道理！

又执行了一遍ps，

如这个马赛克图一样，由于程序执行的时候就在程序目录底下，造成worker就偷懒简写了，而前面全写的路径则只是python的路径。

煎鱼：这不一样的坑。。

领导：我不管，你给我再看看。

煎鱼：好吧。

煎鱼想了一下，既然已经有了这个进程的信息，那么我只要将这个进程的信息拿到不就行了吗，这些信息可都在/proc/[pid]/里面！

这里的这个对照容器的work进程号是94710，既然执行程序的时候是在程序目录了，那就查这个进程的执行程序目录就找到了：

ll /proc/94710/cwd

/proc/[pid]/cwd是一个link，它链接到执行程序的目录，所以直接进去目录也是可以的。至于执行程序的命令，ps里面有，/proc/[pid]/cmdline里面也有。

煎鱼：擦！原来这么简单的路径啊。。早知道随便找找就好了。。领导你进去这个目录启动这个程序就好了。

领导：好的小鱼。咦？不对啊，我已经进去这个目录了，用了这个命令怎么还是不能启动。

煎鱼：噢是这样的，容器在启动这个worker程序的时候，还需要添加了几个环境变量再启动worker，你现在还没有所以还不行。

领导：那我知道个啥环境变量，我不管！

煎鱼：好吧，我们来看看有啥环境变量。

strings /proc/94710/environ

领导：你这个我看不懂啊，像打了马赛克一样。

煎鱼：这个就是这个进程启动时刻的所有环境变量，你把缺了的加进去，再执行程序的启动命令就行。

领导：好吧。

于是在领导的“请求”下，煎鱼手动打完一个个环境变量并export了，最后“开心地”启动了worker。

proc是Linux里面特有的伪文件系统，里面的数据存于内存而非外存。

系统中运行的进程都有着对应的文件目录，对应着/proc/[pid]，里面存在进程的相关信息，包括以上故事中的程序启动文件目录（/proc/[pid]/cwd）、程序启动命令（/proc/[pid]/cmdline）、程序启动时刻环境变量（/proc/[pid]/environ）等。

还有很多有用的命令。

/proc/[pid]/auxv

/proc/[pid]/auxv包含传递给进程的 ELF 解释器信息，格式是每一项都是一个 unsigned long长度的 ID 加上一个 unsigned long 长度的值。最后一项以连续的两个 0x00 开头。

/proc/[pid]/comm

/proc/[pid]/comm包含进程的命令名。

/proc/[pid]/exe

/proc/[pid]/exe为实际运行程序的符号链接。

/proc/[pid]/maps

/proc/[pid]/maps显示进程的内存区域映射信息。

/proc/[pid]/stack

/proc/[pid]/stack示当前进程的内核调用栈信息，只有内核编译时打开了CONFIG_STACKTRACE编译选项，才会生成这个文件。

/proc/[pid]/statm

/proc/[pid]/statm显示进程所占用内存大小的统计信息。包含七个值，度量单位是 page(page大小可通过 getconf PAGESIZE 得到)。

/proc/[pid]/status

/proc/[pid]/status 包含进程的状态信息。其很多内容与/proc/[pid]/stat和/proc/[pid]/statm相同，但是却是以一种更清晰地方式展现出来。

先这样吧

若有错误之处请指出，更多地关注煎鱼。