◆ 介绍/proc

在过去那些糟糕的日子里，只能通过直接访问内核内存(/dev/kmem)获取进程数据，比如运行ps(1)命令时。为了实现这种访问，需要超级用户权限，而且步骤相当复杂。Sun公司从UNIX SVR4开始解决了进程数据访问问题，现在，可以简单地通过/proc访问进程数据。

/proc文件系统不是普通意义上的文件系统，它是一个到运行中进程地址空间的访问接口。通过/proc，可以用标准Unix系统调用(比如open()、read()、write()、ioctl()等等)访问进程地址空间。事实上，Solaris ps(1)命令正是利用/proc获取进程状态。

S (l) 进程状态:

O 正在运行
S 休眠: 进程正在等待某个事件发生/完成
R 可运行: 进程位于运行队列中
Z 僵尸状态: 进程结束了，但是其父进程未处理SIGCHLD信号
T 进程暂停: 可能是任务控制信号所致，或者正在被
跟踪调试

/proc下的大文件对应运行中进程的地址空间，不是标准Unix文件。事实上每个文件名对应运行中进程的PID，文件属主、属组对应进程拥有者的real-uid和primary-gid。权限控制与普通Unix文件一样。文件大小是最令人迷惑的地方，事实上相当好理解，对应进程内存映像大小，并不真正占用硬盘空间，所以你不必担心空间浪费的问题。不要企图删除这些文件！观察图A中列举的/proc例子：

--------------------------------------------------------------------------

$ ls -l /proc
total 43384
-rw------- 1 root root 0 Apr 2 20:07 00000
-rw------- 1 root root 393216 Apr 2 20:07 00001
-rw------- 1 root root 0 Apr 2 20:07 00002
-rw------- 1 root root 0 Apr 2 20:07 00003
-rw------- 1 root root 1695744 Apr 2 20:07 00081
-rw------- 1 root root 1597440 Apr 2 20:07 00083
-rw------- 1 root root 1777664 Apr 2 20:08 00096
-rw------- 1 root root 1683456 Apr 2 20:08 00099
-rw------- 1 root root 1589248 Apr 2 20:08 00101
-rw------- 1 root root 1445888 Apr 2 20:08 00116
-rw------- 1 root root 1404928 Apr 2 20:08 00126
-rw------- 1 root root 798720 Apr 2 20:08 00135
-rw------- 1 root root 1368064 Apr 2 20:08 00195
-rw------- 1 root root 1585152 Apr 2 20:08 00197
-rw------- 1 root root 1368064 Apr 2 20:08 00200
-rw------- 1 root other 225280 Apr 2 20:08 00201
-rw------- 1 root root 1454080 Apr 2 20:08 00203
-rw------- 1 root root 1519616 Apr 2 20:14 00243
-rw------- 1 rthomas wheel 1499136 Apr 2 20:14 00245
-rw------- 1 rthomas wheel 806912 Apr 2 20:16 00261
$

图A: /proc例子

--------------------------------------------------------------------------

操作/proc下文件的方式和操作普通Unix文件一样，可以使用所有你熟悉的系统调用，包括ioctl()。在内核中，针对/proc下文件的vnode操作被转向procfs。这意味着操作vnode的系统调用(比如lookuppn())实际上最终转向procfs-savvy系统调用(比如prlookup())。

◆ /proc能告诉我什么

Solaris下使用/proc的工具相当完善，位于/usr/proc/bin目录中。这些工具提供了一种访问任意指定进程临界数据的简捷办法。比如，想知道一个进程已经打开了多少文件，你可以使用crash(1M)(见鬼，我不会)，但是你是root吗？不必担心，可以用/usr/proc/bin/pfiles获取这种信息，图B演示了pfiles(1)命令的使用：

--------------------------------------------------------------------------

[scz@ /export/home/scz]> ps
PID TTY TIME CMD
637 pts/3 0:00 bash
[scz@ /export/home/scz]> pfiles 637
637: -bash
Current rlimit: 64 file descriptors
0: S_IFCHR mode:0620 dev:151,0 ino:196787 uid:500 gid:7 rdev:24,3
O_RDWR
1: S_IFCHR mode:0620 dev:151,0 ino:196787 uid:500 gid:7 rdev:24,3
O_RDWR
2: S_IFCHR mode:0620 dev:151,0 ino:196787 uid:500 gid:7 rdev:24,3
O_RDWR
3: S_IFDOOR mode:0444 dev:191,0 ino:1618164880 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[213]
63: S_IFCHR mode:0620 dev:151,0 ino:196787 uid:500 gid:7 rdev:24,3
O_RDWR FD_CLOEXEC
[scz@ /export/home/scz]>

图B: 使用pfiles(1)命令

--------------------------------------------------------------------------

正如上面演示的，/usr/proc/bin下的命令使用很简单，只需要在命令行上指定PID。然而，留心权限许可设置，与所有普通Unix文件一样，你无权访问那些权限设置上禁止访问的指定PID的进程数据。

花点事件看看proc(1)手册页，熟悉其中介绍的命令，你将学会列举指定进程相关的库、进程信号设置、进程信任设置，你甚至可以暂停、重启进程。

◆ 编写/proc工具

/proc的魅力在于它包含了你可能想知道的关于一个进程的任何信息，你只需要简单地从中获取。/usr/include/sys/procfs.h文件中定义了两个结构，prstatus和prpsinfo，从中可以获取指定进程的很多信息。下面是个例子，开发者想知道他的应用程序究竟占用了多少内存。简单！ls /proc就可以知道了。但是，他还想知道更多细节，他需要知道总的映像大小、常驻部分的大小、堆区(heap)大小、栈区(stack)大小。此外，他希望能够定期跟踪这些数据信息，类似vmstat(1M)那种方式。如上所述，听起来象是一个令人生畏的任务。

译者: Solaris 2.6开始这两个结构定义在/usr/include/sys/old_procfs.h文件中

然而，通过使用/proc文件系统，我们可以使这项编程挑战变得容易些。我们写的这个工具称做memlook，将显示指定PID对应的内存统计信息。此外，可以在命令行上指定一个时间间隔，以便定期重新检测内存利用信息。图C演示了一次简单的输出：

--------------------------------------------------------------------------

$ memlook 245
PID IMAGE RSS HEAP STACK
245 1499136 1044480 24581 8192
$

图C: memlook的输出举例

--------------------------------------------------------------------------

下面是memlook.c的源代码

--------------------------------------------------------------------------
/*
* @(#)memlook.c 1.0 10 Nov 1997
* Robert Owen Thomas robt@cymru.com
* memlook.c -- A process memory utilization reporting tool.
*
* gcc -Wall -O3 -o memlook memlook.c
*/
#pragma ident "@(#)memlook.c 1.0 10 Nov 1997 Robert Owen Thomas robt@cymru.com"

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/signal.h>
#include <sys/syscall.h>
#include <sys/procfs.h>
#include <sys/param.h>
#include <unistd.h>
#include <fcntl.h>

int counter = 10;

int showUsage ( const char * );
void getInfo ( int, int );

int main ( int argc, char * argv[] )
{
int fd, pid, timeloop = 0;
char pidpath[BUFSIZ]; /* /usr/include/stdio.h: #define BUFSIZ 1024 */

switch ( argc )
{
case 2:
break;
case 3:
timeloop = atoi( argv[2] );
break;
default:
showUsage( argv[0] );
break;
} /* end of switch */
pid = atoi( argv[1] );
sprintf( pidpath, "/proc/%-d", pid ); /* -表示向左靠 */
if ( ( fd = open( pidpath, O_RDONLY ) ) < 0 )
{
perror( pidpath );
exit( 1 );
}
if ( 0 < timeloop )
{
for ( ; ; )
{
getInfo( fd, pid );
sleep( timeloop );
}
}
getInfo( fd, pid );
close( fd );
exit( 0 );
} /* end of main */

int showUsage ( const char * progname )
{
fprintf( stderr, "%s: usage: %s < PID > [time delay]\n", progname, progname );
exit( 3 );
} /* end of showUsage */

void getInfo ( int fd, int pid )
{
prpsinfo_t prp;
prstatus_t prs;

if ( ioctl( fd, PIOCPSINFO, &prp ) < 0 )
{
perror( "ioctl" );
exit( 5 );
}
if ( ioctl( fd, PIOCSTATUS, &prs ) < 0 )
{
perror( "ioctl" );
exit( 7 );
}
if ( counter > 9 )
{
fprintf( stdout, "PID\tIMAGE\t\tRSS\t\tHEAP\t\tSTACK\n" );
counter = 0;
}
fprintf( stdout, "%u\t%-9u\t%-9u\t%-15u\t%-15u\n", pid,
( unsigned int )prp.pr_bysize, ( unsigned int )prp.pr_byrssize,
( unsigned int )prs.pr_brksize, ( unsigned int )prs.pr_stksize );
counter++;
} /* end of getInfo */
--------------------------------------------------------------------------

译者: 作者这里利用了ioctl()，而不是直接读取/proc下文件，这样做的好处在于即使系统升级后/proc布局改变，内核中相应ioctl cmd支持也随之改变，对于应用层的开发者，接口一样，源代码可平稳移植。事实上从作者前面举例来看， memlook.c是在Solaris 2.6以前的版本上开发的，但我并未修改就可以直接用在Solaris 2.6上，虽然此时/proc布局已经发生重大变化。

仔细阅读prstatus和prpsinfo结构，寻找那些你敢兴趣的成员。在未能真正掌握这种技术之前不要针对/proc文件系统使用write()或者ioctl()。针对特定进程胡乱做write()调用，结果未知。

◆ 结论

当痛苦调试程序或者试图获取指定进程状态的时候，/proc文件系统将是你强有力的支持者。通过它可以创建更强大的工具，获取更多信息。