崩溃恢复

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