组循环

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