群組迴圈

當一個 lnode 成為作用中的時，從其雙親一直上到 root lnode 也都會一起被啟用。這時如果發現稍早已經遇到其中一個 lnode 的雙親，那麼 kernel 就發現了一個群組迴圈。

如果限制資料庫已經損壞，便可能會發生群組迴圈，其中 lnode 的其中一個祖先也會是它的子。kernel 會特意地打破迴圈而自動將它連結至排程樹，然後將其連結為 root lnode 之下的一個群組。因此位於迴圈與排程樹連結的那一點的 lnode 就會變成最頂層群組的 header。如此一來，此群組的成員很可能會承繼原本所沒有的權限或更高的限制。

原因

設定排程群組雙親時可以藉由 limadm(1MSRM) 來防止群組迴圈的產生。生成群組迴圈的唯一原因是由於限制資料庫出現損壞的情況。這是一個嚴重的問題，而且可能會造成 Solaris Resource Manager 一些其他的問題，因為限制資料庫對其操作而言非常重要。

後果

當 kernel 發現一個群組迴圈之後，它會無聲地將迴圈中的一個 lnode 直接附加在 root lnode 的下方。因為迴圈沒有開頭或結尾，所以它無法決定哪一個才是最頂層的 lnode。

修正

此種排程樹結構的問題會自行修正，因為 kernel 會將 lnode 附加至 root lnode 之上。因為迴圈是由其上的任意一點被附加的，管理員必須決定要將 lnode 附加在何處，也必須檢查迴圈中其他每位成員的附加點。

您可以列出所有 root lnode 的子 lnode 來查看自動群組迴圈修補的結果。指令

% limreport 'sgroup==0' - uid lname

會列出以 root lnode 為其雙親的所有 lnode。如果任何列出的 lnode 不應該是 root lnode 的子，它們可能是被附加在 root lnode 下方的群組迴圈頂端。

管理員在找到群組迴圈之後最擔心的問題就是，如果群組迴圈的確是由於限制資料庫發生損壞而產生的話，那麼會有更嚴重的問題發生。如果管理員懷疑限制資料庫有損壞的情況，最好是馬上查驗該檔，以確定它是否已被損壞，然後採取適當的補救措施。請參閱"恢復故障"中，就如何偵測與修正損壞的限制資料庫所做的詳細說明。

恢復故障

當 Solaris 系統發生故障時，管理員必須考慮許多問題。不過如果當時在使用 Solaris Resource Manager 系統的話，還必須額外考慮其他幾點﹕

• 可能由於磁碟錯誤或是其他原因而造成限制資料庫被損壞。

• 系統故障期間的limdaemon(1MSRM) 操作，特別是與連結時間使用量收費有關。

以下各節會詳細討論這幾個方面，並且在適當時提出處理問題的建議。

限制資料庫損壞

Solaris Resource Manager 非常努力維護限制資料庫，損壞不太可能發生。然而如果的確有損壞發生的話，會對管理員帶來嚴重的問題，因為這個資料庫是 Solaris Resource Manager 操作的基礎。因此應該仔細調查任何潛在的損壞，並且在偵測到之後立即加以處理。

徵兆

沒有任何一種徵兆可以確切地判定限制資料庫已經遭受損壞，不過可以藉由確認幾種跡象來決定損壞的限制資料庫﹕

• 若是 Solaris Resource Manager kernel 偵測到一個群組迴圈，很可能表示限制資料庫已經被損壞。Solaris Resource Manager 會非常小心地防範群組迴圈的發生，唯一可能會發生的原因是一個 sgroup 屬性由於某種原因被損壞。請參閱"群組迴圈"中更詳細的說明資訊。

• 當使用者嘗試登入時，如果看到一個 'No limits information available' 的訊息，其登入的操作被回絕。這可能是因為限制資料庫損壞，因而導致其 flag.real 屬性被清除，連帶地刪除其 lnode。它不只會影響被刪除的 lnode，也會影響所有被孤立的 lnode（請參閱孤立 Lnode 一節中的說明）。請注意，如果沒有為帳號建立任何 lnode，或是它已經不小心被刪除的話，'No limits information available' 訊息也會出現，因此不能單憑這個訊息就斷定限制資料庫已經損壞。

• 使用量或限制屬性突然出現不合理的數值。某些使用者可能會因此而忽然達到使用量的限制。

• 使用者突然抱怨喪失使用權限或是獲得未預期的權限，因為權限旗標損壞。

如果管理員懷疑限制資料庫中出現任何損壞，最佳的偵測方法就是使用 limreport(1SRM) 來要求一份 lnode 清單，其中應該在某個範圍之內的屬性值忽然變為在範圍之外。這個指令也可以用來列出那些 flag.real 為 clear 的 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. 將系統帶回單一使用者模式後再回到多重使用者模式，以確保終止目前所有的登入階段作業，而使用者必須在重新啟動精靈之後才能再次登入。