checking ufs filesystems

　　demobox console login:

　　尽管打印的消息变少了，但 SMF 使得引导过程更加清晰。每个服务在 /var/svc/log 目录（对于在单个用户的重大事件之前启动的服务，则为 /etc/svc/volatile 目录）中都有一个日志文件，指出服务启动的时间和方式、是否成功启动，以及在初始化期间可能打印的所有消息。如果在引导期间发生严重问题，则您可以在维护模式下登录到控制台，并可使用 svcs(1) 命令帮助诊断此问题。即使问题导致引导挂起（如上面提到的 NIS 故障）时也是如此。最后，新的 "-m" 引导选项（请参见 kernel(1M)）允许您将引导过程配置得更加详细，可以在每个服务启动时打印一条简单消息。

　　您可能还会注意到，中止进程后进程会“拒绝中止。例如：

　　# ps -fp `pgrep -d, sendmail`

　　UID PID PPID C STIME TTY TIME CMD

　　root 330 1 0 14:21:05 ? 0:00 /usr/lib/sendmail -bd -q15m

　　smmsp 331 1 0 14:21:05 ? 0:00 /usr/lib/sendmail -Ac -q15m

　　# pkill -9 sendmail

　　# ps -fp `pgrep -d, sendmail`

　　UID PID PPID C STIME TTY TIME CMD

　　root 530 1 0 14:51:02 ? 0:00 /usr/lib/sendmail -bd -q15m

　　smmsp 531 1 0 14:51:02 ? 0:00 /usr/lib/sendmail -Ac -q15m

　　初看起来，尽管使用了 kill -9，却似乎没有发生任何情况。但是请注意，PID 是不同的，并且进程的启动时间已经更改；事实上，旧的 sendmail 进程确实已经中止。

　　通过 SMF，Solaris 内核可以考虑服务、此服务的进程和其他服务（负责重新启动此服务）之间的关系。此重新启动关系与 Sun 的新技术紧密集成，用于在 Solaris 上进行故障管理，从而允许 SMF 重新启动程序了解服务进程失败的原因是管理员错误、相关服务故障、软件错误还是根本的硬件故障。只要在任何服务故障之后捕获到此信息，SMF 就会通知相应的重新启动程序，该程序将确定是通过将此服务置于维护模式来禁用服务（因为它看起来存在问题），还是自动重新启动该服务。缺省的 SMF 重新启动程序 svc.startd 负责启动和重新启动 Solaris 系统上的大多数服务。在以上示例中，svc.startd 注意到 sendmail 已中止，针对此情况记录了一条消息，并自动重新启动 sendmail。

标签：