当一个 lnode 被激活后,在 root lnode 以下的其所有父节点均被激活。作为这个进程的结果,如果看到 lnode 中的某一个有以前曾经遇到过的父节点,则内核就发现了一个 组循环。
如果限制数据库遭到损坏,则有可能出现组循环,即某一 lnode 的某一前辈还是它的一个子节点。当内核发现一个组循环时,内核会毫无声息的自动将其断开,将其作为一个组连接到 root lnode 的底下,从而将循环连接进调度树。内核无法确定哪个是最顶层的 lnode,因为该循环没有起始和终止。这意味着,位于循环连接到调度树处的 lnode 变成了最顶层组的一个组长。该组的成员就有可能继承特权或者获得本来无法得到的更高的限制。
在设置调度组父节点时使用 limadm 就可以避免组循环。造成组循环的唯一原因就是限制数据库遭到损坏。这是一个严重的故障,可能会在 Solaris Resource Manager 导致各种各样其它的困难,因为限制数据库是 Solaris Resource Manager 操作的根基。
就调度树的结构而言,该故障是自行更正的,因为内核将该 lnode 附加到 root lnode 上。鉴于附加是从循环的随意一点进行的,管理员必须确定应当在哪里附加 lnode,并且应当检查循环中其它每个成员的附加点。
列出是 root lnode 的子节点的 lnode 就能看到自动组循环修理的结果。命令:
% limreport 'sgroup==0' - uid lname |
可列出有 root lnode 做为父节点的所有 lnode。如果列出任何不应为 root lnode 的子节点的 lnode,则它们可能是已经附加到 root lnode下方的组循环的顶端。
因为组循环的起因是限制数据库出现了损坏,所以当一个组循环被监测到时,管理员主要关心的就是有可能出现许多更为严重的故障。如果管理员怀疑是限制数据库出现了损坏,则最好对该文件进行某些有效性检查,以确定其是否已遭到损坏,然后采取补救措施。请参考 崩溃恢复,了解有关监测和更正损坏限制数据库的细节。