第 11章 疑難排解

本章將提供有關診斷 Solaris Resource Manager 操作問題的指標。

如果您需要其他協助，請與您的 Sun 軟體支援供應商聯繫。

與使用者有關的問題

使用者無法登入

• 有 nologin 或 noattach 旗標為 set 的使用者。

• 使用者的 onelogin 旗標為 set，而且已經從另一個終端機或視窗登入。

• 使用者已經達到連結時間使用量的限制。使用者再次登入之前，必須等候使用量消減，或者管理員可以變更使用者的 terminal.usage 屬性或 terminal.limit 屬性，以賦予該使用者額外的終端機連結時間。

• 使用者的 lnode 可能存在，但是卻已被孤立，因為其雙親 lnode 已經移除。請參見孤立的 lnode。

上述所列的所有 Solaris Resource Manager 限制皆不適用於超級使用者。

雖然使用者能夠登入系統　假如沒有 lnode 與使用者的 UID 相對應(沒有為使用者帳戶設立的一個 lnode)，本問題乃是由一個訊息所指出：沒有限制資訊可供參考。請參閱 孤立的 lnode。

使用者未被告知達到限制

在 Solaris Resource Manager 的一般性操作期間，登入的使用者會在到達限制時收到通知訊息。使用者可能錯失這些通知並且不清楚造成其問題的原因，只覺得系統似乎有點問題。不過系統管理員一定會接到有關限制的通知。

Solaris Resource Manager 常駐程式 limdaemon 會負責通知訊息的遞送。管理員有幾種方法可以調查通知訊息是否有被送給使用者﹕

• 主控台視窗是處於隱藏狀態。如果一位使用者是使用一個特定的視窗來登入，然後又開啟了其他幾個視窗，把登入視窗遮住的話，就有可能看不到遞送到其登入視窗的訊息。

• 沒有執行 limdaemon 程式。

• limdaemon 無法動態配置額外的記憶體以維護其內部的結構。如果發生這種情況，limdaemon 會在第一次無法取得充分記憶體時，在系統主控台上顯示一個診斷訊息。它會繼續嘗試取得記憶體，不過第一次嘗試之後不會發出警告。

• utmp 檔已經損毀或是遺失。limdaemon 必須根據此檔來決定使用者登入的終端機，好在必要時將通知訊息傳遞至該終端機。如果 utmp 檔損毀或遺失，主控台會報告一個錯誤訊息，因而抑制通知訊息的遞送。

• 由於系統限制，limdaemon 無法遞送一個訊息。例如若 limdaemon 需要在要遞送訊息的終端機之上開啟一個視窗卻無法如此，訊息就會被丟棄。

無法變更使用者群組

sgroup 屬性決定 lnode 在排程樹中的雙親。此階層結構可用來管制資源使用量並且排程 CPU 的資源使用。因此在修改 sgroup 屬性時必須注意幾種安全上的問題，以避免無法補救的錯誤發生，並且不要因規避問題而繞過 Solaris Resource Manager。

要修改 sgroup 屬性，使用者需要下列其中一種權限﹕

• 身為超級使用者；

• 有一個 set 的 uselimadm 旗標；

• 有一個 set 的 admin 旗標並為被變更 lnode 的群組標頭。

孤立的 lnode 無法稱為其他 lnode 的雙親。請參見孤立的 lnode。

使用者經常超出限制

檢查是否是以下任何狀況所造成的問題﹕

• 使用者的管理性限制設定太低，無法滿足其需求。

• 使用量屬性並未消減。管理員應該負責確保所有可更新資源的裝置類目都確實地執行消減（包括終端機裝置類目）。一般而言，可以執行 limdaemon(1MSRM) 指令以定期進行消減的動作。如果沒有為一個可更新資源進行消減，該資源的使用量屬性就會繼續增加，直到到達其限制為止。

• 消減期太長。limdaemon 的執行頻率應該設定以符合最短消減間隔的精確度。

• 一個可更新資源的消減屬性太小，或是間隔屬性太長。如果可更新資源在一段時間間隔之內的消減設定低於該資源的一般佔用率，則使用量屬性便會逐漸增加，直到到達其限制為止。

未預期的通知訊息

受到達到限制影響的任何使用者都會收到通知訊息。因此如果到達一個群組限制之後，群組標頭和在排程階層之下的所有使用者都會收到一個通知訊息。

如果一位使用者附加至另一個 lnode 之上，就可能會達到某種限制。使用者雖然沒有收到通知訊息，但是所有其他的使用者都會收到此訊息。對受到限制的群組而言，問題的原因可能不夠明顯。

終端機連結時間並未更新

這個問題最可能的原因就是 limdaemon 程式沒有執行。 limdaemon 會定期性地為目前所有登入的使用者更新終端機裝置類目中的使用量以及累計的屬性。一般而言，它會被 Solaris Resource Manager init.d 程序檔啟始。

系統執行緩慢

附加至 root lnode 的程序

基於系統管理的目的，附加至 root lnode 上的程序幾乎都可取得其所需的所有 CPU 資源。因此如果有一個需要大量 CPU 的程序附加至 root lnode 上的話，它會完全佔用一個 CPU，而使其他 lnode 上的程序變得緩慢甚而完全停止作用。

請仔細考慮下列數點以防止上述的問題發生﹕

• 管理員應該登入一個他們自己的 lnode 來進行一般性的作業，而不是附加至 root lnode 之上。如果他們基於某種原因必須附加至 root lnode 的話，應該注意不要使用任何會佔用太多 CPU 資源的應用程式，如編譯程式等。要在不附加至 root lnode 的情況下使用一個超級使用者的 UID，管理員可以使用 su(1) 指令。

• init.d 指令集可以改成使用 srmuser 程式，以便將所有常駐程式附加到它們自己的 lnodes，從而使它們附加（透過承繼）到 root lnode。然而此類解決方法不能被例行的建議。因為非常大數量的檔案需要被編輯，這可能是一個負擔，而且本實行不能禁止稍後將修補程式整合到系統的能力。有一個不需要本工作被手動執行的解決方法已在調查中。

  對於比 1.0 新的 Solaris Resource Manager 發行版，在 /usr/srm/unsupport 目錄中提供的指令集 sbin_rc2，可用於部份地解決這個問題。

一個作為 setuid-root 執行的程式不會自動附加至 root lnode 之上。一般而言，處理仍然附加至建立該處理的雙親的 lnode 之上，只變更其有效 UID。

CPU 資源不受 Solaris Resource Manager 的控制

Solaris Resource Manager 只控制 SHR 排程類別中的處理所使用的 CPU。如果其他排程類別提出優先順序較高的過度要求，特別是即時 (RT) 及系統 (SYS) 兩種類別的話，那麼 SHR 就只能排程剩餘的 CPU 資源。

RT 類別的使用會與 Solaris Resource Manager 軟體控制系統的功能相衝突。即時處理會取得完整的系統存取權，特別是因為這樣它們才能做出即時的回應（速度大約是數百微秒）。SHR 類別中執行的處理優先順序顯然會比即時類別中的任何處理都來得低，而 Solaris Resource Manager 又沒有即時處理的控制權。即時處理會輕易地佔用所有可用的資源，幾乎不留給 Solaris Resource Manager 任何資源好配置給剩餘的處理。

值得一提的是，有一種完全在 SYS 類別中執行的系統服務，稱為 NFS 伺服器。Solaris Resource Manager 無法控制 NFS 常駐程式，因為它們在 SYS 中執行。Solaris Resource Manager 產品配置處理機資源的功能，在提供密集 NFS 服務的系統之上可能效果不彰。

當處理正在執行 kernel 內碼（在一個系統呼叫之內）時，不適用一般性的時間分割強取規則。大多數的系統呼叫只能在到達一個強取點之前完成有限的工作量。不過如果有許多更密集的系統呼叫在影響系統的話，可能會造成整體回應效率的降低，並且超出排程類別的控制範圍之外。

如果系統缺乏可用的真正記憶體，那麼隨著缺頁率的增加及處理交換的增加，會造成 I/O 的瓶頸而導致 CPU 的 kernel 佔用增加。在 I/O 上等待太長的時間可能會喪失 CPU 的執行功率。同樣地，這也在排程類別的控制範圍之外。

SHR 排程類別是一種分時 (TS) 排程器。它和 TS 以及 IA 排程器一樣使用相同的全域優先順序範圍。SHR 不適合用來與 TS 和 IA 混合使用，除非是用於將所有處理移入或移出 SHR 類別時。以 SHR 和 TS 類別的混合處理來進行系統操作，會使這兩種類別排程行為的品質降低。因此 Solaris Resource Manager 不允許非 root 的處理將自己或其他處理移入 TS 或 IA 類別。RT 類別使用一種代用優先順序範圍，而且可以和 SHR 類別一起使用，就好像使用 TS 和 IA 類別一樣。

假如超級使用者所執行的程序包含程式碼，而且這程式碼使用 priocntl(2) 系統呼叫，而不以 setpriority(3C) 程式庫常式來調整處理優先順序的內碼，那麼它們會將目標處理移入另一個排程類別中（通常是 TS）。因為 setpriority 程式庫常式內碼可以使 SHR 的 priocntl 介面與 TS 的介面二進位相容，因此能避免問題發生。指令： -c 可以使用 ps(1)-d 可以使用 priocntl(1) 選項來顯示程序的排程類別。

超級使用者權限處理也會發生同樣的難題，它堅持使用 priocntl(2) 來管理處理的排程類別成員身份。

孤立的 lnode

一個孤立的 lnode 是沒有雙親 lnode 的。這是管理員應該關心的問題，因為 Solaris Resource Manager 會阻止處理被附加至任何孤立或是在排程樹中有任何孤立祖先的 lnode。

Kernel 會檢查 sgroup 屬性的變更，以防止排程群組雙親因無效的更改而建立孤立行。

孤立一個 lnode 的主要後果是，它無法再附加任何處理。既然無法連結任何程序，該 lnode 便無法用於登入。因此使用對應帳號來登入的嘗試都會失敗。

管理員偵測孤立 lnode 的簡單方法就是使用有內建孤立行標識符的 limreport 指令。指令：

% limreport orphan - uid sgroup lname

會列出 UID，排程群組雙親以及有孤立 lnode 的使用者登入名稱。sgroup 屬性可以用來決定哪一個 lnode 位於樹形結構孤立段落的頂端。

找到一個孤立 lnode 之後，管理員應採取的第一步便是找出排程樹孤立段落的頂端，因為這個 lnode 需要被重新附加。如果沒有正確地識別出孤立段落的頂端，那麼便只有孤立段落的一部份會被附加至樹形之上。

一旦找到孤立段落的頂端之後，擁有充份權限的管理員便可以使用 limadm 來將頂端孤立 lnode 的 sgroup 屬性設定為排程樹中的一個有效的 lnode。因此孤立 lnode 會被重新附加至樹形結構，成為有效的 lnode 所帶領的群組成員。 limadm 可以確認將要應用的新排程群組雙親可以被啟動，因而確保被變更的 lnode 將不再是孤立的。

另外管理員還可以建立一個新的使用者，讓其 UID 等於孤立 lnode 的 sgroup 屬性中的 UID。這樣便能自動重新附加樹形結構的孤立段落。

群組迴圈

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

如果限制資料庫已經損毀，便可能會發生群組迴圈，其中 lnode 的其中一個祖先也會是它的子節點。kernel 會特意地打破迴圈而自動將它連結至排程樹，然後將其連結為 root lnode 之下的一個群組。因此位於迴圈與排程樹連結的那一點的 lnode 就會變成最頂層群組的標頭。這表示在迴圈連於排程樹的點上的 lnode 變成一個最高群組的群組領導者。因此，群組的成員可能繼承超過他們所該繼承的權利或限制。

原因

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

修正

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

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

% limreport 'sgroup==0' - uid lname

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

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

解決 UID 衝突

要確認系統為 srmidle、srmlost 及 srmother 所指派的 UID 與任何現存的 UID 沒有任何衝突，請鍵入﹕

# /usr/bin/egrep 41\|42\|43 /etc/passwd

如果出現任何衝突，您可以編輯密碼及陰影檔來變更 UID，/etc/passwd 和 /etc/shadow。

恢復故障

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

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

• 在系統故障時，特別是與連線時間使用量付款有關的 limdaemon 操作可能有問題。

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

限制資料庫損毀

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 來要求一份 lnode 清單，其屬性值應該在某個範圍之內。如果數值在報告的範圍以外，就會發生損毀。limreport 也可用來列出具有明確 flag.real的 lnodes。這就表示其密碼對映中的帳號沒有 lnode。

修正

如果偵測到損毀情況，管理員應該回復限制資料庫尚未損毀的版本及相符的設置。如果限制資料庫損毀的範圍並不大，管理員也許能夠保存其他所有 lnode 的內容，然後使用 limreport 和 limadm 指令，重新將它們載入一個新的限制資料庫中。如果找不到最近的限制資料庫副本的話，這可能是一個較理想的方法，新的限制資料庫現在會包含最近的使用量及累計屬性。 第 5章, 管理 lnode一節中包含儲存與回復限制資料庫程序的相關資訊。如果只是遺失 lnode 這種簡單的問題的話，只要使用 limadm 指令來重新建立它們便可。

Limdaemon 使連結時間遺失

如果 limdaemon 基於任何原因而終止，所有目前登入的使用者便不會被收取任何連結時間使用量的款項。再者，重新啟動 limdaemon 之後，任何登入的使用者都會繼續免費使用該終端機。這是因為常駐程式有賴於 login 所遞送的登入通知，在它用來計算連結時間使用量的內部結構中，建立一個 Solaris Resource Manager 登入階段作業記錄。因此，每當它啟始之後，在接到第一個通知之前，都不會建立任何 Solaris Resource Manager 登入階段作業。

如果 limdaemon 由於系統故障而終止的話，這通常不是什麼大問題，因為故障也會導致其他處理終止。那麼直到系統被重新啟動之前，登入階段作業也無法恢復執行。

如果 limdaemon 是因為其他原因而終止，管理員有兩種選擇﹕

1. 立即重新啟動常駐程式，然後忽略已經登入的使用者遺失的終端機連結時間應付款項。這表示一位使用者可以不斷地免費使用一部終端機，直到被發現而登出為止。

2. 將系統帶回單一使用者模式後再回到多重使用者模式，以確保終止目前所有的登入階段作業，而使用者必須在重新啟動常駐程式之後才能再次登入。