崩溃恢复

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

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

• 在系统发生故障，特别是与连接时间利用率相关时，运行 limdaemon 就可能造成故障。

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

限制数据库损坏

Solaris Resource Manager 对限制数据库的维护是可靠的，一般不会发生崩溃。但如果真的发生崩溃，则这就是管理员的主要当务之急，因为该数据库对于 Solaris Resource Manager 的运行非常重要。应该对任何潜在的崩溃进行调查，一旦检测出来就应该加以修复。

症状

只根据一项症状是不可能可靠地确定限制数据库是否已经崩溃的，但是有若干种因素可以潜在地表明限制数据库的崩溃：

• Solaris Resource Manager 内核对组循环进行的检测可以很好地表明限制数据库已经崩溃。组循环受到 Solaris Resource Manager 的严格预防，只有当 sgroup 属性以某种方式发生崩溃时，它们才可能发生。有关详情，请参阅组循环。

• 用户在尝试登录时会看到屏幕上显示'没有限制信息可供使用'信息，用户登录被拒绝。如果限制数据库使其 flag.real 属性被清除，并有效地删除了其 lnode，则这样的情况就会发生。它不仅会影响被删除的 lnode，而且还能影响任何被孤立的 lnode（有关详情，请参阅 孤立 lnode）。请注意，只有当没有为帐户创建 lnode，或当 lnode 被故意删除后，才会显示'没有限制信息可供使用'信息，所以它并不能清楚地表明限制数据库已经崩溃。

• 利用率或限制属性中突然出现不真实的数值。这会导致某些用户突然出现限制。

• 用户突然抱怨因为特权标志的崩溃而失去了特权或未预期的特权。

如果管理员怀疑限制数据库发生了崩溃，检测崩溃的最好方法就是使用 limreport 请求其属性应具有在已知范围内的数值的 lnode 列表。如果报告了该范围之外的值，则损坏已发生。limreport 还可用来列示拥有清空的 flag.real 的 lnode。这将显示不存在 lnode 的口令映射中的帐户。

更正

当检测出崩溃后，管理员应采用限制数据库的未崩溃版本。如果崩溃仅限于限制数据库的一小部分，则管理员就能保存所有其它 lnode 的内容，并采用 limreport 和 limadm 命令把它们重新装载到刷新的限制数据库中。如果没有限制数据库的最新副本，则这样做就是最好的方法，因为新的限制数据库现在包含最新的利用率和应计属性。保存和恢复限制数据库的步骤如 第 5 章，管理 lnode所示。对于丢失了 lnode 等简单情况，只需使用 limadm 命令重新创建 lnode 就足够了。

因 limdaemon 而导致连接时间损失

如果 limdaemon 因某种原因而中断，则当前登录的所有用户都将停止对任何连接时间利用率的计费。此外，当 limdaemon 重新启动时，已经登录的任何用户将继续免费使用这些终端。这是因为守护程序必须依靠来自 login 的登录通知才能在其用于计算连接时间利用率的内部结构中建立 Solaris Resource Manager 登录对话记录。所以，无论何时，只要它启动，则在接收到第一个通知之前就不会建立 Solaris Resource Manager 登录对话。

一般地，如果 limdaemon 因为系统崩溃而中断，这就不会构成问题，因为崩溃也会使其它进程中断。这样，登录对话在系统重新启动之前就不能重新开始。

如果 limdaemon 因某些其它原因而中断，则管理员有两个选择：

1. 立即重新启动守护程序，并忽略已经登录的用户的终端连接时间的丢失计费。这可能表示除非被标识或退出，否则用户就能无限期免费使用一个终端。

2. 使系统返回单用户模式，然后再返回多用户模式，从而确保所有当前登录对话均被中断，且用户只能在守护程序重新启动后重新登录。