第 9 章 故障排除

包含本节是为了在诊断 Solaris Resource Manager 操作方面的故障方面为管理员提供协助。

用户无法登录

• 没有与用户的 UID 对应的 lnode。这意味着管理员尚未为该用户的住户设置 lnode。该故障是通过下面的消息识别出来的：No limits information is available（无限制信息可用）。请参考 "孤立 lnode"。

• 用户的 nologin 或者 noattach 标志得到设置。

• 用户的 onelogin 标志得到设置，业已在另一终端或者窗口登录。

• 用户业已达到连接时间限制。用户必须等到利用率衰变才能再次登录，也可以让管理员更改用户的 terminal.usage 属性或者 terminal.limit 属性，以使用户得到更多终端连接时间。

• 用户的 lnode 可能存在，但由于其父 lnode 遭到删除而被孤立。请参阅 "孤立 lnode"。

上面所列的 Solaris Resource Manager 限制均不适用于根用户。

用户未得到达到限制的通知

在 Solaris Resource Manager 的正常操作过程中，已登录用户一旦达到某个限制就会收到通知消息。用户可能会没有意识到当前故障的起因，而系统将看似古怪。但是，系统管理员将得到通知。

通知消息的提交是由 Solaris Resource Manager 的守护程序 limdaemon 执行的。如果通知消息未被提交，管理员可以对好几种可能可能性进行调查：

• 控制台窗口被隐藏。如果用户使用某一具体的窗口登录，然后又打开其它窗口遮盖了登录窗口，则用户也可能会错过提交给其登录窗口的消息。

• limdaemon(1MSRM)程序未运行。

• limdaemon 无法为了维持其内部结构而动态分配更多的内存。如果真的如此，则 limdaemon 会在第一次没能获得充足内存时在系统控制台上显示一条诊断消息。它会继续尝试获得内存，但第一次尝试以后再失败，就不再发出消息。

• utmp 文件损坏或者丢失。limdaemon 需要这个文件才能确定用户所登录的终端，以及向这些终端发送通知消息。如果 utmp 文件损坏或者丢失，则在控制台上报告一个错误消息，并抑制通知消息的提交。

• 由于某个系统限制，limdaemon 无法提交一条消息。例如，如果limdaemon 为了提交消息而需要在某个终端上打开一个窗口，但又无法打开，则放弃该消息。

无法更改用户的组

sgroup 属性用于确定 lnode 在调度树中的父节点。该分层结构用于调节资源的利用率和调度 CPU。出于这一原因，为 sgroup 属性的更改设置了多个安全性预防措施，以避免对其进行更改时发生疏忽错误，以及防止绕开 Solaris Resource Manager 。

如要修改 sgroup 属性，用户需要有下列特权：

• 是超级用户；

• 其 uselimadm 标志得到设置；

• 其 admin 标志得到设置，且是正要更改的 lnode 的组头目。

孤立 lnode 无法成为其它 lnode 的父节点。请参阅 "孤立 lnode"。

遭损坏的限制数据库

如果限制数据库发生损坏，则管理员应当给予极大关注。借助单独一个症状无法可靠地确定限制数据库业已遭到损坏，但是有若干的标志可能会反映出限制数据库发生损坏，应当予以鉴别。

如果证实发生了损坏，则管理员应当返回到一个未遭损坏的限制数据库版本，并对配置进行匹配。如果损坏只是限于限制数据库一小部分，则管理员有可能将所有其它 lnode 的内容保存起来，并借助 limreport(1SRM)和 limadm(1MSRM) 命令将其重新装入一个新的限制数据库。

如要了解更多有关监测和更正损坏限制数据库的信息，请参阅 "限制数据库损坏"。

终端连接时间没有更新

该故障的最可能的起因是 limdaemon(1MSRM)程序没在运行。limdaemon 周期性地为当前所有已登录的用户，对终端设备类别终端利用率和应计属性进行更新。典型情形是，从 Solaris Resource Manager 的init.d(4)正文将其启动。

用户频繁超过限制

其起因可能有多个：

• 对于用户的要求来讲，用户的管理限制设置得过低。

• 利用率属性没在衰变。管理员负责确保所有的可更新资源的设备类别均得到衰变（其中包括终端设备类别）。典型情形是通过经常性地执行limdaemon(1MSRM) 命令。如果某一可更新资源没有给予衰变，则该资源的利用率属性会持续增加，一直到达到其限制。

• 执行 limdecay 的间隔过长。limdaemon(1MSRM) 的执行频率应当设置为满足最短衰变间隔的粒度。

• 某一可更新资源的衰变属性过小，或者间隔属性过大。如果某一可更新资源在一个给定时间间隔的衰变设置低于该资源的典型消耗率，则利用率属性将逐渐增加，一直到达到其限制。

系统运行缓慢

根 lnode 上的进程

出于系统管理的原因，附加到根 lnode 的进程得到其所需的所有 CPU 资源。因此，与 CPU 绑定的进程如果被附加到根 lnode，则会独占某一 CPU，使得其它 lnode 上的进程运行缓慢或者停止运行。

可以采取下列预防措施来防止此类情况的发生：

• 管理员进行常规使用时，应当登录到其自己的 lnode，而不是附加到根 lnode。如果出于某个原因需要附加到根 lnode，则应当小心，不要使用任何 CPU 密集型的应用程序。诸如编译程序。如要在不附加到根 lnode 的条件下使用超级用户的 UID，管理员可以使用su(1)命令。

• 应当将 init.d(4)正文改为使用 srmuser(1SRM) 程序，以便使所有的守护程序附加到其自己的 lnode，而不是（通过继承）附加到根lnode。

作为 setuid-root 而运行的程序并不自动附加到根 lnode。通常，该进程保持附加到创建它的父节点的 lnode，而只有有效 UID 被更改。

CPU Resources 不受 Solaris Resource Manager 控制

Solaris Resource Manager 只对 SHR 调度类中的进程的 CPU 使用加以控制。如果其它调度类，特别是 real-time (RT) 和 system (SYS)，以较高优先权提出过多要求的话，则 SHR 只能对剩余的 CPU资源进行调度。

RT 类的使用与 Solaris Resource Manager 软件对系统的控制能力相冲突。实时进程获得对系统的完全访问，特别是为了能够提供实时的响应（通常是几万分之一秒）。依照定义，SHR 类中运行的进程所拥有的优先权比任何实时运行的进程都要低，而 Solaris Resource Manager 并不控制 RT 进程。实时进程很容易就用尽全部的可用内存，使得没有为 Solaris Resource Manager 留下任何资源用于分配给其余的进程。

一个值得注意的完全在 SYS 类中运行的系统服务就是 NFS 服务器。 Solaris Resource Manager 无法控制 NFS 守护程序，因为它们是在 SYS 中运行的。在提供广泛的 NFS 服务的系统上， Solaris Resource Manager 产品的分配处理器资源的能力可能会遭到削弱。

在进程（在系统调用内）执行核心代码时，通常的时间片抢先规则并不适用。大多数系统调用只是进行了适中数量的工作就到达了一个抢先点。但是，如果系统承担的是更加剧烈的系统调用的高负载，则有可能导致整体响应下降，并且是在调度类的控制范围之外。

如果系统缺乏可用的实在内存，则随着页面故障率以及进程交换的增加，所导致的 I/O 瓶颈使得核心的 CPU 消耗增加。等候 I/O 时间太长，可能指示着 CPU 容量损失。而这又是在调度类的控制范围之外。

SHR 调度类是一个分时（TS）调度器。其所使用的全局优先权变程与 TS和 IA 调度器相同，除非是为了过渡而将所有的进程移入或者移出 SHR类，否则将 SHR 与 TS 和 TA 混在一起使用是不合适的。SHR 和 TS 类混合进行系统操作，将使两类的调度性能均遭到削弱。出于这个原因， Solaris Resource Manager 防止非根进程将其自身或者其它进程移到 TS 或者 IA 类。RT 类使用一个替代性的优先权变程，可以与 SHR 类一同使用，就象与 TS 和 TA 类一同使用那样。

如果根所运行的进程为了调整进程优先权，含有直接使用 priocntl(2) 系统调用而非使用 setpriority(3C) 库例行程序的代码，则这些代码可以将目标进程移入另一调度类（典型情况为 TS）。setpriority(3C) 库例行程序代码说明了一个事实，即priocntl(2)与 SHR 的接口与到 TS 的接口是二进制兼容的，从而避免了故障。-ps(1)的 c 选项或者 -priocntl(1)的 d 选项可以用于显示进程的调度类。

根优先权进程明确地使用 priocntl(2)来管理进程的调度类成员，因而也存在同样的困难。

意外通知消息

任何受达到限制影响的用户，均会收到通知消息。因此，如果达到某一组限制，则组头目以及分层结构中组头目下面的所有用户均将收到一条通知消息。

如果某一用户附加到另一 lnode，则有可能达到限制。该用户不会收到通知消息，但所有其它受影响的用户会收到。受影响的组可能不会晓得该故障的起因。

孤立 lnode

孤立 lnode 的定义是，拥有一个并不存在的父 lnode 的 lnode。这是 Solaris Resource Manager 管理员需要关心的，因为 Solaris Resource Manager 防止进程附加到任何遭到孤立或者其在调度树中的前辈遭到孤立的 lnode。

核心对 sgroup 属性的变化进行检查，以避免由于对调度组父节点的变更而创建孤立 lnode。

遭到孤立的 lnode 的主要作用在于，它可能不再拥有任何附加的进程。鉴于无法附加任何进程，该 lnode 也就无法用于登录。借助相对应的帐户尝试登录将会失败。

管理员可以用来监测孤立 lnode 的最为便利的方法是使用带内置孤立识别符的 limreport(1SRM) 命令。命令

% limreport orphan - uid sgroup lname

会列出拥有孤立 lnode 的用户的 UID、调度组符层次和登录名称。sgroup 属性可以用于确定是哪个 lnode 位于树的孤立部分的顶部。

管理员在发现一个孤立 lnode 时所应采取的第一个步骤就是，找出调度树的孤立部分的顶部，因为这正是需要重新附加的 lnode。如果没能正确识别孤立部分的顶部，则会只有孤立部分的一部分被重新附加到树。

一旦确定了孤立部分的顶部，拥有充足特权的管理员就可以使用 limadm(1MSRM)来将最顶端的孤立 lnode 的 sgroup 属性设置为调度树内的一个有效的 lnode。这将促使孤立 lnode 作为有效 lnode 所带领的组的一个成员而重新附加到树。limadm用于验证所要应用的新的调度组父节点可以被激活，以便确保所更改的 lnode 不会再次被孤立。

作为替代方案，管理员也可以创建一个新的用户，其 UID 等于孤立 lnode的 sgroup 属性中的 UID。这将促使树的孤立部分自动重新得到附加。

组循环

当促使某一 lnode 活动时，往上一直到根 lnode，其所有的父节点也被激活。在这个过程中，如果发现曾经遇到过其中一个 lnode 的父节点，则核心发现了一个组循环。

如果限制数据库遭到损坏，则有可能出现组循环，即某一 lnode 的某一前辈还是它的一个子节点。核心会自动随意将其断开，将其作为一个组连接到根 lnode 的底下，从而将循环连接进调度树。这意味着，位于循环连接到调度树处的 lnode 变成了最顶层组的一个组头目。该组的成员就有可能继承特权或者获得本来无法得到的更高的限制。

起因

在设置调度组父节点时使用 limadm(1MSRM) 就可以避免组循环。造成组循环的唯一原因就是限制数据库遭到损坏。这是一个严重的故障，可能会在 Solaris Resource Manager 导致各种各样其它的困难，因为限制数据库是 Solaris Resource Manager 操作的根基。

作用

核心发现一个组循环时，就安静地将循环中的一个 lnode 直接附加到到根lnode 的底下。核心无法确定哪一个是最高层的 lnode，因为该循环没有开始也没有结尾。

更正

就调度树的结构而言，该故障是自行更正的，因为核心将该 lnode 附加到根 lnode。鉴于附加是从循环的随意一点进行的，管理员必须确定应当在哪里附加 lnode，并且应当检查循环中其它每个成员的附加点。

自动组循环修复的结果，可以借助列出根 lnode 的子 lnode 来进行查看。命令

% limreport 'sgroup==0' - uid lname

将列出所有将根 lnode 作为其父节点的 lnode。如果列出了任何不应当是根 lnode 的子 lnode 的 lnode，则这些 lnode 可能就是业已被附加到根 lnode 的某个组循环的顶部。

当管理员监测到一个组循环时，其主要的当务之急就是有可能出现更为严重的故障，因为组循环的起因是限制数据库出现了损坏。如果管理员怀疑是限制数据库出现了损坏，则最好对该文件进行某些有效性检查，以确定其是否已遭到损坏，然后采取补给措施。请参考 "崩溃恢复"，了解有关监测和更正损坏限制数据库的细节。

崩溃恢复

当 Solaris 系统出现某一故障时，管理员会有许多当务之急，但所使用的系统是 Solaris Resource Manager 时，则需要进行其它一些考虑。其中有：

• 可能因为磁盘错误或者其它某个原因，限制数据库业已遭到损坏。

• 在故障过程中，limdaemon(1MSRM)的操作，尤其是与连接时间利用率记费有关的操作。

下面几节探讨上述问题的细节，并为把握局势提出一些合适的建议。

限制数据库损坏

Solaris Resource Manager 对限制数据库的维护是十分健壮的，损坏是不太可能发生的。但是如果损坏真的发生了，则管理员应当给予极大关注，因为该数据库是 Solaris Resource Manager 操作的根基。任何潜在的损坏均应予以调查，如果确实监测到，就予以更正。。

症状

如果限制数据库发生损坏，则管理员应当给予极大关注。借助单独一个症状无法可靠地确定限制数据库业已遭到损坏，但是有若干的标志可能会反映出限制数据库发生损坏，应当予以鉴别。

• Solaris Resource Manager 核心监测到一个组循环，这是对限制数据库遭到损坏的一个正面指示。 Solaris Resource Manager 严格避免组循环，而发生组循环的唯一途径是由于某种原因，sgroup 属性遭到损坏。请参考 "组循环"，了解更多细节。

• 用户在试图登录时，看到"无限制信息可用"消息显示出来，且登录遭到拒绝。发生此情形，有可能是由于限制数据库遭到损坏，而使得用户的 flag.real 属性被清空，从而有效地删除了用户的 lnode。这不但会影响到所删除的 lnode，还会影响到任何孤立的 lnode（有关细节请参考"孤立 lnode" 一节）。注意，如果没有为帐户创建 lnode，或者所创建的 lnode 遭到故意删除，则也会出现"无限制信息可用"消息，所以，这并非明确指示限制数据库业已遭到损坏。

• 利用率或者限制属性突然出现不现实的值。这有可能使得某些用户突然命中限制。

• 用户突然抱怨失去特权或者意外获得特权，这是由特权标志损坏引起的。

如果管理员怀疑限制数据库发生了损坏，则最有可能用来监测的方法就是使用 limreport(1SRM)，请求获得属性超出某个已知正常范围的 lnode的列表。该命令也可以用于列出 flag.real 被清空的 lnode。这会指示出口令映射中的并不存在 lnode 的帐户。

处理

如果监测到了损坏，则管理员应当返回到一个未遭损坏的限制数据库版本。如果损坏只是限于限制数据库一小部分，则管理员有可能将所有其它lnode 的内容保存起来，并借助 limreport(1SRM) 和 limadm(1MSRM)命令将其重新装入一个新的限制数据库。如果没有最近的限制数据库副本可用的话，则建议进行此类操作，否则新的限制数据库就会包含最近的利用率和应计属性。保存和恢复限制数据库的过程，在管理 lnode 一节中有描述。对于 lnode 丢失的简单情形，只要借助 limadm命令加以创建就足够了。

由于 limdaemon 而损失连接时间

如果 limdaemon(1MSRM) 由于任何原因而终止，则停止为当前已登录的所有用户的连接时间利用率记费。而且，当 limdaemon(1MSRM) 重新起动时，任何已登录的用户可以继续免费使用终端。这是因为守护程序依赖于来自login(1)的登录通知，才能在其内部结构中建立一个 Solaris Resource Manager 登录会话期间记录，而它又是使用该记录来计算连接时间利用率的。因此，每当其一起动，在首次收到通知之前，是不会建立任何 Solaris Resource Manager 登录会话期间的。

典型情况是，如果是由于系统崩溃才使 limdaemon 终止的，则没有什么问题，因为其它进程也会因为崩溃而终止。而登录会话期间只有在系统重新起动之后才会再次开始。

如果 limdaemon(1MSRM) 是由于其它某种原因才终止的，则管理员有两个选择：

1. 立刻重新起动守护程序，并忽略所损失的对已登录用户的终端连接时间的记费。这有可能意味着，某个用户如果不被察觉和注销，将可以无止境地免费使用某一终端。

2. 使系统回到单用户模式，然后再回到多用户模式，从而确保终止当前所有的登录会话期间，且用户只能在守护程序得到重新起动后再次登录。