3

在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

clipboard.png

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


P_Chou水冗
5.1k 声望256 粉丝

大数据spark/flink/hadoop/elasticsearch/kafka架构与开发