如何查看linux的系统log日志

日志文件详细地记录了系统每天发生的各种各样的事件。用户可以通过日志文件检查错误产生的原因，或者在受到攻击和黑客入侵时追踪攻击者的踪迹。日志的两个比较重要的作用是：审核和监测。Linux系统的日志主要分为两种类型：1．进程所属日志由用户进程或其他系统服务进程自行生成的日志，比如服务器上的access_log与error_log日志文件。2．syslog消息系统syslog记录的日志，任何希望记录日志的系统进程或者用户进程都可以给调用syslog来记录日志。日志系统可以划分为三个子系统：1． 连接时间日志--由多个程序执行，把纪录写入到/var/log/wtmp和/var/run/utmp，login等程序更新wtmp和utmp文件，使系统管理员能够跟踪谁在何时登录到系统。2． 进程统计--由系统内核执行。当一个进程终止时，为每个进程往进程统计文件（pacct或acct）中写一个纪录。进程统计的目的是为系统中的基本服务提供命令使用统计。3． 错误日志--由syslogd（8）执行。各种系统守护进程、用户程序和内核通过syslog（3）向文件/var/log/messages报告值得注意的事件。2．察看日志文件Linux系统所有的日志文件都在/var/log下，且必须有root权限才能察看。日志文件其实是纯文本的文件，每一行就是一个消息。察看方式有很多。1． cat命令。日志文件总是很大的，因为从第一次启动Linux开始，消息都累积在日志文件中。如果这个文件不只一页，那么就会因为显示滚动得太快看不清文件的内容。2． 文本编辑器。最好也不要用文本编辑器打开日志文件，这是因为一方面很耗费内存，另一方面不允许随意改动日志文件。3．用more或less那样的分页显示程序。4．用grep查找特定的消息。每一行表示一个消息，而且都由四个域的固定格式组成：n 时间标签（timestamp），表示消息发出的日期和时间 n 主机名（hostname）（在我们的例子中主机名为escher），表示生成消息的计算机的名字。如果只有一台计算机，主机名就可能没有必要了。但是，如果在网络环境中使用syslog，那么就可能要把不同主机的消息发送到一台服务器上集中处理。n 生成消息的子系统的名字。可以是"kernel"，表示消息来自内核，或者是进程的名字，表示发出消息的程序的名字。在方括号里的是进程的PID。n 消息（message），剩下的部分就是消息的内容。举例：在[root@localhost root]# 提示符下输入：tail /var/log/messagesJan 05 21:55:51 localhost last message repeated 3 timesJan 05 21:55:51 localhost kernel: [drm] AGP 0.99 on Intel i810 @ 0xf0000000 128MBJan 05 21:55:51 localhost kernel: [drm] Initialized i830 1.3.2 20021108 on minor0Jan 05 21:55:51 localhost kernel: mtrr: base(0xf0000000) is not aligned on a size(0x12c000) boundaryJan 05 21:56:35 localhost 1月 28 21:56:35 gdm(pam_unix)[4079]: session opened for user root by (uid=0)Jan 05 21:56:39 localhost 1月 28 21:56:39 gconfd (root-4162): 正在启动（版本 2.2.0），pid 4162 用户"root"Jan 05 21:56:39 localhost 1月 28 21:56:39 gconfd (root-4162): 解析的地址"xml:readonly:/etc/gconf/gconf.xml.mandatory"指向位于 0 的只读配置源Jan 05 21:56:39 localhost 1月 28 21:56:39 gconfd (root-4162): 解析的地址"xml:readwrite:/root/.gconf"指向位于 1 的可写入配置源Jan 05 21:56:39 localhost 1月 28 21:56:39 gconfd (root-4162): 解析的地址"xml:readonly:/etc/gconf/gconf.xml.defaults"指向位于 2 的只读配置源Jan 05 21:58:20 localhost kernel: MSDOS FS: IO charset cp936值得注意的是，与连接时间日志不同，进程统计子系统默认不激活，它必须启动。在Linux系统中启动进程统计使用accton命令，必须用root身份来运行。accton命令的形式为：acctonfile，file必须事先存在。先使用touch命令创建pacct文件：touch/var/log/pacct，然后运行accton：accton/var/log/pacct。一旦accton被激活，就可以使用lastcomm命令监测系统中任何时候执行的命令。若要关闭统计，可以使用不带任何参数的accton命令。3．日志系统工作原理及配置3.1 syslog它同closelog, openlog共同给system logger发送消息。Linux内核由很多子系统组成，包括网络、文件访问、内存管理等。子系统需要给用户传送一些消息，这些消息内容包括消息的来源及其重要性等。所有的子系统都要把消息送到一个可以维护的公用消息区。于是，就有了一个叫Syslog的程序。 这个程序负责接收消息（比如：系统核心和许多系统程序产生的错误信息、警告信息和其他信息，每个信息都包括重要级），并把消息分发到合适的地方。通常情况下，所有的消息都被记录到特定的文件——日志文件中（通常是/var/adm或/var/log目录下的messages文件），特别重要的消息也会在用户终端窗口上显示出来。syslog工具有两个重要文件：syslogd和syslog.Conf 它能接受访问系统的日志信息并且根据 "/etc/syslog.conf" 配置文件中的指令处理这些信息。守护进程和内核提供了访问系统的日志信息。因此，任何希望生成日志信息的程序都可以向 syslog 接口呼叫生成该信息。3.2 syslogd守护进程　　就象其它复杂的 *** 作系统那样，Linux也是由很多不同的子系统组成的。有些叫做daemon的程序一直在后台运行（daemon：守护神之意。也就是说，他们"默默无闻"，不需要和用户交互），处理一些象打印、发送邮件、建立Internet连接，等等日常工作。每一个子系统发出日志消息的时候都会给消息指定一个类型。一个消息分成两个部分："设备（facility）"和"级别(level)"。"设备"标识发出消息的子系统，可以把同一类型的消息组合在一起，"级别"表示消息的重要性，其范围从debug（最不重要）到emerg（最重要），facility和level组合起来称为priority。（详细解释参照5.3）/usr/include/sys/syslog.h中对此有相关的定义。用户看不到daemon程序，因为它们没有窗口和用户界面。但是，这些程序有时候也要给用户传递一些信息。为了实现这个目的，就需要一个特殊的机制。syslogd就是daemon的一个很好的例子，它在后台运行并且把消息从日志区转移到日志文件中去。函数接口 #include void openlog( char * , int , int ) 其中，可以是以下值的OR组合： LOG_CONS : 如果消息无法送到syslogd，直接输出到系统console。 LOG_NDELAY : 立即打开到syslogd的连接，默认连接是在第一次写入讯息时才打开的。 LOG_PERROR : 将消息也同时送到stderr 上 LOG_PID : 将PID记录到每个消息中 void syslog( int , char * ) 其中，是facility和level的OR组合 void closelog( void ) 一般只需要用syslog()函数，其他函数可以不用。3.3 syslog.conf这是一个非常重要的文件。位于"/etc/"目录下。通知 syslogd 如何根据设备和信息重要级别来报告信息。该文件使用下面的形式：facility.levelactionsyslog.conf 的第一列facility.level用来指定日志功能和日志级别，中间用.隔开，可以使用*来匹配所有的日志功能和日志级别。第二列action是消息的分发目标。空白行和以#开头的行是注释，可以忽略。Facility.level 字段也被称做选择域（seletor）。n facility 指定 syslog 功能，主要包括以下这些：auth 由 pam_pwdb 报告的认证活动。authpriv 包括特权信息如用户名在内的认证活动cron 与 cron 和 at 有关的信息。daemon 与 inetd 守护进程有关的信息。kern 内核信息，首先通过 klogd 传递。lpr 与打印服务有关的信息。mail 与电子邮件有关的信息mark syslog 内部功能用于生成时间戳news 来自新闻服务器的信息syslog 由 syslog 生成的信息user 由用户程序生成的信息uucp 由 uucp 生成的信息local0----local7 与自定义程序使用，例如使用 local5 做为 ssh 功能* 通配符代表除了 mark 以外的所有功能level 级别，决定讯息的重要性。与每个功能对应的优先级是按一定顺序排列的，emerg 是最高级，其次是 alert，依次类推。缺省时，在 /etc/syslog.conf 记录中指定的级别为该级别和更高级别。如果希望使用确定的级别可以使用两个运算符号！(不等)和=。例如：user.=info 表示告知 syslog 接受所有在 info 级别上的 user 功能信息。 n 以下的等级重要性逐次递减: emerg 该系统不可用alert需要立即被修改的条件crit 阻止某些工具或子系统功能实现的错误条件err 阻止工具或某些子系统部分功能实现的错误条件warning 预警信息notice 具有重要性的普通条件info 提供信息的消息debug不包含函数条件或问题的其他信息none 没有重要级，通常用于排错*所有级别，除了nonen action 字段为动作域，所表示的活动具有许多灵活性，特别是，可以使用名称管道的作用是可以使 syslogd 生成后处理信息。syslog 主要支持以下活动：file 将消息追加到指定的文件尾terminal 或 print 完全的串行或并行设备标志符@host 远程的日志服务器username 将消息写到指定的用户named pipe指定使用 mkfifo 命令来创建的 FIFO 文件的绝对路径。* 将消息写到所有的用户选择域指明消息的类型和优先级；动作域指明syslogd接收到一个与选择标准相匹配的消息时所执行的动作。每个选项是由设备和优先级组成。当指明一个优先级时，syslogd将纪录一个拥有相同或更高优先级的消息。比如如果指明"crit"，则所有标为crit、alert和emerg的消息将被纪录。每行的行动域指明当选择域选择了一个给定消息后应该把他发送到什么地方。以下是一个实际站点的配置（syslog.conf）文件：# Store critical stuff in critical#*.=critkern.none/var/adm/critical这个将把所有信息以优先权的crit保存在/var/adm/critical文件中，除了一些内核信息# Kernel messages are first, stored in the kernel# file, critical messages and higher ones also go# to another host and to the console#kern.* /var/adm/kernelkern.crit@finlandiakern.crit/dev/consolekern.infokern.!err /var/adm/kernel-info第一条代码指引一些内核设备访问文件/var/adm/kernel的信息。第二条代码直接引导所有拥有crit和更高优先权的内核信息访问远程主机。如果它们也存储在远程主机上，仍旧可以试着找到毁坏的原因。第四行说明syslogd 保存了所有拥有info 到warning优先级的内核信息在/var/adm/kernel-info文件夹下。所有err和更高优先级的被排除在外。# The tcp wrapper loggs with mail.info, we display# all the connections on tty12#mail.=info /dev/tty12这个引导所有使用mail.info (in source LOG_MAIL LOG_INFO)的信息到/dev/tty12下，第12个控制台。例如tcpwrapper tcpd(8)载缺省时使用这个 # Store all mail concerning stuff in a filemail.*mail.!=info /var/adm/mail模式匹配了所有具有mail功能的信息，除了拥有info优先级的。他们将被保存在文件/var/adm/mail中# Log all mail.info and news.info messages to info#mail,news.=info /var/adm/info提取所有具有mail.info 或news.info 功能优先级的信息存储在文件/var/adm/info中# Log info and notice messages to messages file#*.=info*.=notice\mail.none /var/log/messages使所有syslogd日志中具有info 或notice功能的信息存储在文件/var/log/messages中，除了所有mail功能的信息# Log info messages to messages file#*.=info\mail,news.none /var/log/messages这个声明使syslogd日志中所有具有info优先权的信息存储在/var/log/messages文件中。但是一些有mail 或news功能的信息不能被存储。# Emergency messages will be displayed using wall#*.=emerg *这行代码告诉syslogd写所有紧急信息到所有当前登陆用户日志中。这个将被实现# Messages of the priority alert will be directed# to the operator#*.alert root,joey*.* @finlandia这个代码指引所有具有alert 或更高级权限的信息到终端 *** 作。第二行代码引导所有信息到叫做finlandia的远程主机。这个代码非常有用，特别是在所有syslog信息将被保存到一台机器上的群集计算机。3.4 klogd 守护进程klog是一个从UNIX内核接受消息的设备 klogd守护进程获得并记录 Linux 内核信息。通常，syslogd 会记录 klogd传来的所有信息。也就是说，klogd会读取内核信息，并转发到syslogd进程。然而，如果调用带有 -f filename 变量的 klogd时，klogd 就在 filename 中记录所有信息，而不是传给 syslogd。当指定另外一个文件进行日志记录时，klogd就向该文件中写入所有级别或优先权。Klogd 中没有和 /etc/syslog.conf 类似的配置文件。使用 klogd 而避免使用syslogd 的好处在于可以查找大量错误。总结其中，箭头代表发送消息给目标进程或者将信息写入目标文件。图1 Linux日志系统日志管理及日志保护 logrotate程序用来帮助用户管理日志文件，它以自己的守护进程工作。logrotate周期性地旋转日志文件，可以周期性地把每个日志文件重命名成一个备份名字，然后让它的守护进程开始使用一个日志文件的新的拷贝。在/var/log/下产生如maillog、maillog.1、maillog.2、boot.log.1、boot.log.2之类的文件。它由一个配置文件驱动，该文件是/etc/logroatate.conf。以下是logroatate.conf文件例子：# see "man logrotate" for details# rotate log files weeklyweekly#以7天为一个周期# keep 4 weeks worth of backlogsrotate 4#每隔4周备份日志文件# send errors to rooterrors root#发生错误向root报告# create new (empty) log files after rotating old onescreate#转完旧的日志文件就创建新的日志文件# uncomment this if you want your log files compressed#compress#指定是否压缩日志文件# RPM packages drop log rotation information into this directoryinclude /etc/logrotate.d# no packages own lastlog or wtmp -- we'll rotate them here/var/log/wtmp {monthlycreate 0664 root utmprotate 1}# system-specific logs may be configured here 在网络应用中，有一种保护日志的方式，在网络中设定一台秘密的syslog主机，把这台主机的网卡设为混杂模式，用来监听子网内所有的syslog包，这样把所有需要传送日志的主机配置为向一台不存在的主机发送日志即可。这样即使黑客攻陷了目标主机，也无法通过syslog.conf文件找到备份日志的主机，那只是一个不存在的主机。实际 *** 作中还可以辅以交换机的配置，以确保syslog包可以被备份日志主机上的syslog进程接受到。比如把syslog.conf中的传送日志主机设为@192.168.0.13，但实际网络中不存在这个日志主机，实际可能是192.168.0.250或者其他主机正在接受syslog包。

教科书里的Linux代码例子都已作古，所以看到的代码不能当真，领会意思就行了

比如以前的init进程的启动代码

execve(init_filename,argv_init,envp_init)

现在改为

static void run_init_process(char *init_filename)

{

argv_init[0] = init_filename

kernel_execve(init_filename, argv_init, envp_init)

}

好的，聪明人就发现，linux内核中调用用户空间的程序可以使用init这样的方式，调用 kernel_execve

不过内核还是提供了更好的辅助接口call_usermodehelper，自然最后也是调用kernel_execve

调用特定的内核函数（系统调用）是 GNU/Linux 中软件开发的原本就有的组成部分。但如果方向反过来呢，内核空间调用用户空间？确实有一些有这种特性的应用程序需要每天使用。例如，当内核找到一个设备， 这时需要加载某个模块，进程如何处理？动态模块加载在内核通过 usermode-helper 进程进行。

让我们从探索 usermode-helper 应用程序编程接口（API）以及在内核中使用的例子开始。 然后，使用 API 构造一个示例应用程序，以便更好地理解其工作原理与局限。

usermode-helper API

usermode-helper API 是个很简单的 API，其选项为用户熟知。例如，要创建一个用户空间进程，通常只要设置名称为 executable，选项都为 executable，以及一组环境变量（指向 execve 主页）。创建内核进程也是一样。但由于创建内核空间进程，还需要设置一些额外选项。

内核版本

本文探讨的是 2.6.27 版内核的 usermode-helper API。

表 1 展示的是 usermode-helper API 中一组关键的内核函数

表 1. usermode-helper API 中的核心函数

API 函数

描述

call_usermodehelper_setup准备 user-land 调用的处理函数

call_usermodehelper_setkeys设置 helper 的会话密钥

call_usermodehelper_setcleanup为 helper 设置一个清空函数

call_usermodehelper_stdinpipe为 helper 创建 stdin 管道

call_usermodehelper_exec调用 user-land

表 2 中还有一些简化函数，它们封装了的几个内核函数（用一个调用代替多个调用）。这些简化函数在很多情况下都很有用，因此尽可能使用他们。

表 2. usermode-helper API 的简化

API 函数

描述

call_usermodehelper调用 user-land

call_usermodehelper_pipe使用 stdin 管道调用 user-land

call_usermodehelper_keys使用会话密钥调用 user-land

让我们先浏览一遍这些核心函数，然后探索简化函数提供了哪些功能。核心 API 使用了一个称为subprocess_info 结构的处理函数引用进行 *** 作。该结构（可在 ./kernel/kmod.c 中找到）集合了给定的 usermode-helper 实例的所有必需元素。该结构引用从 call_usermodehelper_setup 调用返回。该结构（以及后续调用）将会在 call_usermodehelper_setkeys（用于存储凭证）、call_usermodehelper_setcleanup 以及 call_usermodehelper_stdinpipe 的调用中进一步配置。最后，一旦配置完成，就可通过调用 call_usermodehelper_exec 来调用配置好的用户模式应用程序。

声明

该方法提供了一个从内核调用用户空间应用程序必需的函数。尽管这项功能有合理用途，还应仔细考虑是否需要其他实现。这是一个方法，但其他方法会更合适。

核心函数提供了最大程度的控制，其中 helper 函数在单个调用中完成了大部分工作。管道相关调用（call_usermodehelper_stdinpipe 和 helper 函数 call_usermodehelper_pipe）创建了一个相联管道供 helper 使用。具体地说，创建了管道（内核中的文件结构）。用户空间应用程序对管道可读，内核对管道可写。对于本文，核心转储只是使用 usermode-helper 管道的应用程序。在该应用程序（./fs/exec.c do_coredump()）中，核心转储通过管道从内核空间写到用户空间。

这些函数与 sub_processinfo 以及 subprocess_info 结构的细节之间的关系如图 1 所示。

图 1. Usermode-helper API 关系

表 2 中的简化函数内部执行 call_usermodehelper_setup 函数和 call_usermodehelper_exec 函数。表 2 中最后两个调用分别调用的是 call_usermodehelper_setkeys 和 call_usermodehelper_stdinpipe。可以在 ./kernel/kmod.c 找到 call_usermodehelper_pipe 和 call_usermodehelper 的代码，在 ./include/linux/kmod.h 中找到 call_usermodhelper_keys 的代码。

为什么要从内核调用用户空间应用程序？

现在让我们看一看 usermode-helper API 所使用的内核空间。表 3 提供的并不是专门的应用程序列表，而是一些有趣应用的示例。

表 3. 内核中的 usermode-helper API 应用程序

应用程序

源文件位置

内核模块调用./kernel/kmod.c

电源管理./kernel/sys.c

控制组./kernel/cgroup.c

安全密匙生成./security/keys/request_key.c

内核事件交付./lib/kobject_uevent.c

最直接的 usermode-helper API 应用程序是从内核空间加载内核模块。request_module 函数封装了 usermode-helper API 的功能并提供了简单的接口。在一个常用的模块中，内核指定一个设备或所需服务并调用 request_module 来加载模块。通过使用 usermode-helper API，模块通过 modprobe 加载到内核（应用程序通过 request_module 在用户空间被调用）。

与模块加载类似的应用程序是设备热插拔（在运行时添加或删除设备）。该特性是通过使用 usermode-helper API，调用用户空间的 /sbin/hotplug 工具实现的。

关于 usermode-helper API 的一个有趣的应用程序（通过 request_module） 是文本搜索 API（./lib/textsearch.c）。该应用程序在内核中提供了一个可配置的文本搜索基础架构。该应用程序使用 usermode-helper API 将搜索算法当作可加载模块进行动态加载。在 2.6.30 内核版本中，支持三个算法，包括 Boyer-Moore（./lib/ts_bm.c），简单固定状态机方法（./lib/ts_fsm.c），以及 Knuth-Morris-Pratt 算法（./lib/ts_kmp.c）。

usermode-helper API 还支持 Linux 按照顺序关闭系统。当需要系统关闭电源时，内核调用用户空间的 /sbin/poweroff 命令来完成。其他应用程序如 表 3 所示，表中附有其源文件位置。

Usermode-helper API 内部

在 kernel/kmod.c 中可以找到 usermode-helper API 的源代码 和 API（展示了主要的用作内核空间的内核模块加载器）。这个实现使用 kernel_execve 完成脏工作（dirty work）。请注意 kernel_execve是在启动时开启 init 进程的函数，而且未使用 usermode-helper API。

usermode-helper API 的实现相当简单直观（见图 2）。usermode-helper 从调用call_usermodehelper_exec 开始执行（它用于从预先配置好的 subprocess_info 结构中清除用户空间应用程序）。该函数接受两个参数：subprocess_info 结构引用和一个枚举类型（不等待、等待进程中止及等待进程完全结束）。subprocess_info（或者是，该结构的 work_struct 元素）然后被压入工作队列（khelper_wq），然后队列异步执行调用。

图 2. usermode-helper API 内部实现

当一个元素放入 khelper_wq 时，工作队列的处理函数就被调用（本例中是__call_usermodehelper），它在 khelper 线程中运行。该函数从将 subprocess_info 结构出队开始，此结构包含所有用户空间调用所需信息。该路径下一步取决于 wait 枚举变量。如果请求者想要等整个进程结束，包含用户空间调用（UMH_WAIT_PROC）或者是根本不等待（UMH_NO_WAIT），那么会从 wait_for_helper 函数创建一个内核线程。否则，请求者只是等待用户空间应用程序被调用（UMH_WAIT_EXEC），但并不完全。这种情况下，会为____call_usermodehelper() 创建一个内核线程。

在 wait_for_helper 线程中，会安装一个 SIGCHLD 信号处理函数，并为 ____call_usermodehelper 创建另一个内核线程。但在 wait_for_helper 线程中，会调用 sys_wait4 来等待____call_usermodehelper 内核线程（由 SIGCHLD 信号指示）结束。然后线程执行必要的清除工作（为UMH_NO_WAIT 释放结构空间或简单地向 call_usermodehelper_exec() 回送一个完成报告）。

函数 ____call_usermodehelper 是实际让应用程序在用户空间启动的地方。该函数首先解锁所有信号并设置会话密钥环。它还安装了 stdin 管道（如果有请求）。进行了一些安装以后，用户空间应用程序通过 kernel_execve（来自 kernel/syscall.c）被调用，此文件包含此前定义的 path、argv 清单（包含用户空间应用程序名称）以及环境。当该进程完成后，此线程通过调用 do_exit() 而产生。

该进程还使用了 Linux 的 completion，它是像信号一样的 *** 作。当 call_usermodehelper_exec 函数被调用后，就会声明 completion。当 subprocess_info 结构放入 khelper_wq 后，会调用wait_for_completion（使用 completion 变量作为参数）。请注意此变量会存储到 subprocess_info 结构作为 complete 字段。当子线程想要唤醒 call_usermodehelper_exec 函数，会调用内核方法complete，并判断来自 subprocess_info 结构的 completion 变量。该调用会解锁此函数使其能继续。可以在 include/linux/completion.h 中找到 API 的实现。

应用程序示例

现在，让我们看看 usermode-helper API 的简单应用。首先看一下标准 API，然后学习如何使用 helper 函数使事情更简单。

在该例中，首先开发了一个简单的调用 API 的可加载内核模块。清单 1 展示了样板模块功能，定义了模块入口和出口函数。这两个函数根据模块的 modprobe（模块入口函数）或 insmod（模块入口函数），以及 rmmod（模块出口函数）被调用。

清单 1. 模块样板函数

#include

#include

#include

MODULE_LICENSE( "GPL" )

static int __init mod_entry_func( void )

{

return umh_test()

}

static void __exit mod_exit_func( void )

{

return

}

module_init( mod_entry_func )

module_exit( mod_exit_func )

usermode-helper API 的使用如 清单 2 所示，其中有详细描述。函数开始是声明所需变量和结构。以subprocess_info 结构开始，它包含所有的执行用户空间调用的信息。该调用在调用call_usermodehelper_setup 时初始化。下一步，定义参数列表，使 argv 被调用。该列表与普通 C 程序中的 argv 列表类似，定义了应用程序（数组第一个元素）和参数列表。需要 NULL 终止符来提示列表末尾。请注意这里的 argc 变量（参数数量）是隐式的，因为 argv 列表的长度已经知道。该例中，应用程序名是 /usr/bin/logger，参数是 help!，然后是 NULL 终止符。下一个所需变量是环境数组（envp）。该数组是一组定义用户空间应用程序执行环境的参数列表。本例中，定义一些常用的参数，这些参数用于定义 shell 并以 NULL 条目结束。

清单 2. 简单的 usermode_helper API 测试

static int umh_test( void )

{

struct subprocess_info *sub_info

char *argv[] = { "/usr/bin/logger", "help!", NULL }

static char *envp[] = {

"HOME=/",

"TERM=linux",

"PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL }

sub_info = call_usermodehelper_setup( argv[0], argv, envp, GFP_ATOMIC )

if (sub_info == NULL) return -ENOMEM

return call_usermodehelper_exec( sub_info, UMH_WAIT_PROC )

}

下一步，调用 call_usermodehelper_setup 来创建已初始化的 subprocess_info 结构。请注意使用了先前初始化的变量以及指示用于内存初始化的 GFP 屏蔽第四个参数。在安装函数内部，调用了kzalloc（分配内核内存并清零）。该函数需要 GFP_ATOMIC 或 GFP_KERNEL 标志（前者定义调用不可以休眠，后者定义可以休眠）。快速测试新结构（即，非 NULL）后，使用 call_usermodehelper_exec 函数继续调用。该函数使用 subprocess_info 结构以及定义是否等待的枚举变量（在 “Usermode-helper API 内部” 一节中有描述）。全部完成！ 模块一旦加载，就可以在 /var/log/messages 文件中看到信息。

还可以通过 call_usermodehelper API 函数进一步简化进程，它同时执行 call_usermodehelper_setup和 call_usermodehelper_exec 函数。如清单 3 所示，它不仅删除函数，还消除了调用者管理subprocess_info 结构的必要性。

清单 3. 更简单的 usermode-helper API 测试

static int umh_test( void )

{

char *argv[] = { "/usr/bin/logger", "help!", NULL }

static char *envp[] = {

"HOME=/",

"TERM=linux",

"PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL }

return call_usermodehelper( argv[0], argv, envp, UMH_WAIT_PROC )

}

请注意在清单 3 中，有着同样的安装并调用（例如初始化 argv 和 envp 数组）的需求。此处惟一的区别是 helper 函数执行 setup 和 exec 函数。

死活都起不来？

如果能起来，root进去后

mount -o remount,rw /

起不来

出现grub界面的时候，上下键让它停在linux启动项选择那里

按e编辑

第二项，最长那个，最后面输入 空格single

回车

按B启动进入单用户模式

如果这步也进不去就拉倒重装吧

能进去再试试上面那个命令

reboot

解决可能性不大

---