在Linux系统中,根据进程号得到进程的命令行参数,常规的做法是读取/proc/{PID}/cmdline
,并用'\0'
分割其中的字符串得到进程的args[]
,例如下面这个例子:
# xxd /proc/7771/cmdline
0000000: 2f69 746f 612f 6170 702f 6d61 7665 2f62 /itoa/app/mave/b
0000010: 696e 2f6d 6176 6500 2d70 002f 6974 6f61 in/mave.-p./itoa
0000020: 2f61 7070 2f6d 6176 6500 /app/mave.
通过分割其中的0x00
(C语言字符串结束符),可以把这个进程args[]
,解析出来:
args[0]=/itoa/app/mave/bin/mave
args[1]=-p
args[2]=/itoa/app/mave
但是有的时候,我们会看到这样的进程cmdline:
# xxd /proc/7276/cmdline
00000000: 6e67 696e 783a 2077 6f72 6b65 7220 7072 nginx: worker pr
00000010: 6f63 6573 7300 0000 0000 0000 0000 0000 ocess...........
00000020: 0000 0000 0000 0000 00 .........
# xxd /proc/3334/cmdline
00000000: 6e67 696e 783a 206d 6173 7465 7220 7072 nginx: master pr
00000010: 6f63 6573 7320 2f75 7372 2f73 6269 6e2f ocess /usr/sbin/
00000020: 6e67 696e 7820 2d63 202f 6574 632f 6e67 nginx -c /etc/ng
00000030: 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.conf
root 7276 3334 0 2月26 ? 00:00:01 nginx: worker process
如果按照ps的解构方式来做,倒也并不困难。
setproctitle
Python有一个第三方库叫setproctitle,作用就是通过修改args来设置process title
。为什么一个看似很简单的事情,需要一个专门的库来做呢,其实这里面另有玄机。
在Linux中,程序的参数存储空间的后面紧跟的就是环境变量的存储位置:因此,过长的title也会损坏环境变量environ
的值。安全的做法是,先将环境变量复制到其他地方,然后修改environ[x]
的指向,接着,复写整个args[]
。示例代码可参考nginx 设置进程title
更多关于cmdline的问题可参考:
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。