在Linux系统中，根据进程号得到进程的命令行参数，常规的做法是读取/proc/{PID}/cmdline，并用'\0'分割其中的字符串得到进程的args[]，例如下面这个例子：

# xxd /proc/7771/cmdline0000000: 2f69 746f 612f 6170 702f 6d61 7665 2f62  /itoa/app/mave/b0000010: 696e 2f6d 6176 6500 2d70 002f 6974 6f61  in/mave.-p./itoa0000020: 2f61 7070 2f6d 6176 6500                 /app/mave.

通过分割其中的0x00(C语言字符串结束符)，可以把这个进程args[]，解析出来：

args[0]=/itoa/app/mave/bin/maveargs[1]=-pargs[2]=/itoa/app/mave

但是有的时候，我们会看到这样的进程cmdline：

# xxd /proc/7276/cmdline00000000: 6e67 696e 783a 2077 6f72 6b65 7220 7072  nginx: worker pr00000010: 6f63 6573 7300 0000 0000 0000 0000 0000  ocess...........00000020: 0000 0000 0000 0000 00                   .........# xxd /proc/3334/cmdline00000000: 6e67 696e 783a 206d 6173 7465 7220 7072  nginx: master pr00000010: 6f63 6573 7320 2f75 7372 2f73 6269 6e2f  ocess /usr/sbin/00000020: 6e67 696e 7820 2d63 202f 6574 632f 6e67  nginx -c /etc/ng00000030: 696e 782f 6e67 696e 782e 636f 6e66       inx/nginx.conf

感觉完全不按套路出牌啊，原本看起来应该是0x00的地方，却用0x20(空格字符)，而且有时，最后还弄了一堆的0x00。如果还按照上面的正规套路解析必然无法达到“满意”的结果。那么这究竟是怎么回事呢？

原来，cmdline中的内容实际上是进程main函数的参数args的内容，正常情况下，进程的args是进程的启动参数。但是，有些进程却偏偏复写了args里面的内容。由于可以随意的改动，所以就会出现各种“自定义”的参数形式，比如上面nginx的做法。

因此，如果试图通过0x00来分割参数，针对一些特殊的进程是不可靠的。不过由于ps程序显示的内容其实就是cmdline中的东西，遇到0x00是当成空格显示的，并且末尾的连续0x00会被忽略。因此，上面nginx的例子，用ps看会是这样：

root      3334     1  0 2月23 ?       00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.confroot      7276  3334  0 2月26 ?       00:00:01 nginx: worker process

如果按照ps的解构方式来做，倒也并不困难。

setproctitle

Python有一个第三方库叫，作用就是通过修改args来设置process title。为什么一个看似很简单的事情，需要一个专门的库来做呢，其实这里面另有玄机。

在Linux中，程序的参数存储空间的后面紧跟的就是环境变量的存储位置：因此，过长的title也会损坏环境变量environ的值。安全的做法是，先将环境变量复制到其他地方，然后修改environ[x]的指向，接着，复写整个args[]。示例代码可参考

更多关于cmdline的问题可参考：