版本的修補程式和修正程式

問題與解決方案

問題： 部份 run 命令集退出值 (exit value) 導致ServiceGuard記錄不正確的錯誤訊息。如果套件 run/halt 命令集的退出值為 7、13或19，則套件管理程式不會正確地解譯這些錯誤訊息。

解決方案： 命令集中現在已能適當地處理這些退出值。

問題： 套件管理程式不接受套件halt命令集的RESTART退出值。套件halt命令集若以RESTART(2)退出，停止後套件不會重新啟動。

解決方案： 命令集現在已能正確地處理重新啟動問題。

問題： 在具備 60 個套件和大量服務的系統上執行cmviewcl 命令時，造成 cmcld使用 50%的CPU。

解決方案： 變更程式碼以便在使用60 個以上的套件時，改善cmviewcl 和其他區域中之效能。

問題：當ServiceGuard調度者(coordinator)節點無法擷取所有在套件的子網路上執行叢集的狀態，而cmsnmpd 與 cmcld失去聯繫，且停止更新與維護 ServiceGuard MIB時，cmsnmpd 子代理程式仍會維持作用，但是 EMS HA 監督程式及ClusterView 無法擷取目前的 ServiceGuard 套件和服務的狀態。使用者會在cmsnmpd 日誌檔
/var/adm/SGsnmpsuba.log中看到下列錯誤訊息：

***Error:  reading status of SUBNET XX.XX.XX.XX

解決方案：叢集 snmp 子代理程式 (cmsnmpd) 已修改為能正確地處理叢集內所有的節點上不存在套件子網路的問題。

問題： 當cmsnmpd子代理程式啟動，或本機節點或叢集關閉期間產生某些ServiceGuard事件時，snmpd代理程式會在/var/adm/snmpd.log檔案內登錄「CloneVarBind: Unable to clone vb->value.os_value」訊息。

解決方案：程式碼已修改為cmsnmpd子代理程式能正確地初始叢集相關的變數，如此便不會再發生錯誤。

問題：cmhaltpkg時，有問題的命令集印出不正確的錯誤訊息。執行cmhaltpkg時，如果套件控制命令集有問題(檔案不存在、無執行權限等)，終端機上會列出下列錯誤訊息：

Unknown error returned from daemon: Error 0

解決方案：命令已能列印適當的錯誤訊息。

問題：當ContinentalClusters 客戶執行ContinentalClusters 命令時，若節點中止，則命令便會產生堆疊追蹤而失效。

解決方案：程式碼已修改為命令會回報正確的資訊，而不會失效。

問題：在某些節點上有額外的子網路 (但其他的節點上則無) 時，cmquerycl命令逾時並失效。出現如下所示的訊息：

Error: Unable to establish communication to node <nodename>. Failed to gather configuration information. 

此外，其他的ServiceGuard命令(例如cmviewcl和
cmhaltpkg)會延遲10 秒。

解決方案：程式碼已修改為利用INADDR_ANY僅送出一次 UDP探測，以確認節點間的路徑是正確的。

問題：在套件ASCII配置檔中，以下列的設定值來配置套件的自動故障轉回失效：

FAILBACK_POLICY AUTOMATIC
STORAGE_GROUP   VxVMdg

其中，VxVMdg是CVM磁碟群組。 以FAILBACK_POLICY AUTOMATIC 配置的套件，在節點重回叢集時應該移回主要的節點。但在此情況時則否。

解決方案：已增加檢查 AUTO_FAILBACK，現已修正程式碼中的上述行為。

問題：新增節點至叢集時，cmapplyconf 命令得到一個如下所示的內部錯誤訊息：

Internal error: Got unexpected generic_ack with no error number from cmclconfd on <nodename>. 
Error: Unable to retrieve configuration file from node <nodename>: Error 0
cmapplyconf : Unable to apply the
configuration.

解決方案：程式碼已修改為在新增節點至叢集時，
cmapplyconf命令會成功。

問題：若停用磁帶保留/釋出 (reserved/release)功能的核心可調整參數時，需要能確保不能使用ServiceGuard共用的磁帶功能之機制。

解決方案：已在共用的磁帶協助程式 cmtaped 中增加檢查，在停用節點上的可調整核心參數 st_ats_enabled時， cmtaped會將節點視為無 ATS 磁帶裝置。亦增加 ATS 配置命令中的檢查，以便當叢集中有一或多個節點停用核心可調整參數時，阻隔 ServiceGuard共用的磁帶配置。

問題：cmviewcl 命令僅顯示套件名稱的前 12 個字元，但是支援40 個字元。

解決方案：在 cmviewcl 輸出中程式碼現在會顯示 40 個字元。

問題：cmcld協助程式會因核心延遲時間( latency)問題，而登錄「timers delayed x.x seconds」(計時器延遲x.x秒) 訊息。ServiceGuard叢集若有兩個以上的節點沒有叢集鎖定，則在因這類延遲時間問題所導致的長時間核心懸滯後，可能會重組為兩個叢集。遇長時間核心懸滯的節點會組成單節點叢集，而叢集中的其他節點則組成另一個叢集。

解決方案：程式碼已修改為修正一個邏輯錯誤，並在叢集重組的後半加入邏輯表達式，確保一個節點無法從一個有三節點以上的叢集中組成另一個叢集。

問題：若所有的心跳網路均長期的嚴重壅塞，或是在極短的時間內任何一個節點上的cmcld協助程式經常發生核心懸滯時，則具有叢集鎖定的雙節點ServiceGuard叢集會重組為兩個叢集。

解決方案：新增一修正程式，以確保不會錯誤地解除叢集鎖定。此外，會在叢集重組的後半加入邏輯表達式以確保叢集鎖定仍然存在。

問題： 找不到 .rhost 和 cmclnodelist檔案，或是不當地設定時，ServiceGuard命令cmquerycl或cmviewcl不再列印錯誤訊息「Permission denied to X」；其中，X是節點的IP 位址；而列印不正確的錯誤訊息，例如：「Error: Unable to establish communication to node Y」。

解決方案： 訊息的日誌層級已改為預設層級，如此使用者便能看到訊息。

問題：即使網路配置中有如「Non-uniform connection detected」( 偵測到不一致的連接)的錯誤，ServiceGuard 命令
cmapplyconf 仍能執行。

解決方案：程式碼已修改為偵測到網路問題時，命令即結束。

問題：有序列連結的 ServiceGuard叢集會在所有的心跳網路轉接器故障時失效；當所有的心跳均使用跨接(crossover)纜線且其中一個節點失效時，它亦會失效。

解決方案： 程式碼已修改為能正確地處理當所有心跳網路轉接器故障時的序列連結配置。

問題：叢集至少被中止一次後，無法在同一節點上重新啟動配置多個 EMS資源的套件。

解決方案： 程式碼已修改為能重新啟動配置多個 EMS資源的套件。

問題：ServiceGuard管理員無法中止Linux叢集。

解決方案：程式碼已修改為能成功地中止 Linux 叢集。

問題：cmcld在叢集重組後異常結束。 實體網路在失去連通性後重新回復時，網路連線 (心跳與一般服務) 會待叢集改組時才會重新建立。實體網路關閉時，無法快速地清除連線。

解決方案： 已修正程式碼新增一個「rcomm health monitor」以監視連線是否正常。程式碼現在會重新建立回應的連線，並切斷無回應的連線。

問題：當資源名稱超過40個字元時，ServiceGuard 的 cmstartres和cmstopres命令會失效，並產生「Resource name should not be longer than 1024 characters」錯誤訊息。

解決方案：程式碼已修改為能正確的比較資源名稱與允許的最長長度。

問題：在極大的壓力測試(stress test) 下，cmcld的記憶體可能會在叢集組成後跳至 128K。

解決方案：程式碼已修改為能預先配置供cmcld作業所需的額外記憶體。

問題：ServiceGuard 協助程式 /usr/lbin/cmcld 將異常結束，並有核心傾印到 /var/adm/cmcluster/core。狀況會在核心中包括各種不同的異常結束訊息和堆疊追蹤(stack trace)。在syslog中沒有任何一致的訊息或訊息模式能預測此情況。通常失效會在進行「事件監視服務程式」時發生。然而，它常為無法解釋的區段違規(segment violation)。使用cmapplyconf或是使用資源的套件有時會導致此問題。

解決方案：程式碼已修改為能正確地執行記憶體「釋放」(free) 作業，如此便不會再發生異常結束的情形。

問題：配置為使用跨多個容體群組檔案系統的套件，在故障轉移時耗時過久。

解決方案：已更新的套件控制命令集樣本讓您能指定並用的容體群組啟用或停用數量、fsck命令，及檔案系統裝載或卸載。預設為舊的模式，即是依序排列這些操作。

問題：當ServiceGuard被告知有一個資源的值已改變時，若僅有其中一個 RESOURCE_UP_VALUE準則未符，它便會認定該資源已關閉 (down)，並讓套件失效。

解決方案：當資源改變值時，程式碼現在會藉由至少檢查是否符合其中一個準則來判斷資源的狀態；若仍認為資源是作用中時，便會讓套件繼續執行。

問題：當子網路故障並隨即回復時，卻使得套件重新啟動而不是故障轉移之相關敘述需要加入文件中。

解決方案： 下版更新《《管理MC/ServiceGuard》》和《《以ServiceGuard OPS Edition規劃OPS叢集》》手冊時將包括下列的聲明：

「附註：套件若相依在子網路上，且在主要節點上的子網路故障，則套件即將關閉。若子網路隨即回復 (於套件在承接節點上重新啟動之前)，則套件便可能在主要節點上重新啟動。因而在此情況時，套件不會切換到叢集內的另一個節點。」

問題：cmmakepkg 線上援助頁中的 RUN_SCRIPT_TIMEOUT 值錯誤。

解決方案：已修正線上援助頁，RUN_SCRIPT_TIMEOUT 和 HALT_SCRIPT_TIMEOUT 值為「秒」而非「毫秒」。

問題： cmrunnode命令失敗，並在 syslog登錄找到不同配置資料的訊息。

解決方案：已修改程式碼，確認 cmrunnode 命令蒐集正確的叢集配置版本；否則便會失敗並送出錯誤訊息。 startup 命令集會重試命令10分鐘，若仍無法成功，便會放棄。

問題： 列印層級 1 或更高的 ns_switch 失敗訊息 (應為層級 0)。

解決方案：已變更程式碼，如此這類訊息便會以層級 0 登錄 (可在線上環境中看到)。

問題：若將具備EMS資源的套件新增至執行A.11.12版或舊版的叢集， 且套件被刪除，叢集並於稍後昇級至 A.11.14版，則在線上新增任何套件時可能會失敗且有 Unknown Error: 3015 訊息。

解決方案：變更程式碼能使用正確的副程式 (routine)， 以便自叢集資料庫完全移除資源。

問題：cmrunnode 報告有匯流排的錯誤 (coredump)。

解決方案：命令會在清除期間，試圖釋出某些已解除配置的記憶體。已修正程式碼，以便在適當的時間釋出記憶體。

問題：cmcld 在收到 DL_UDERROR_IND 錯誤時異常中止。將推出 DLPI 修補程式修正此問題。

解決方案：Service Guard 中的變通解決方案是僅會在長時間頻繁地收到指出有永久性或嚴重問題的 dl_errno 1 訊息時異常中止。否則，問題便是暫時性的且會被忽略掉。

問題： cmcheckconf 與 cmapplyconf 命令失敗，且收到「EMS subclass request failed」錯誤訊息。

解決方案：已修正在 ServiceGuard 命令與 EMS 工具組之間的連結問題。

問題：在使用 EMS 監視程式時，ServiceGuard 不會正確地處理 RM_NOT_READY 狀況。

解決方案：已新增程式碼，以便在監視程式傳回
RM_NOT_READY 時，重試註冊資源。

問題：當相依 EMS 資源傳回 RM_NOT_READY 時，無法啟動套件。

解決方案：已新增程式碼，以便在監視程式傳回
RM_NOT_READY 時，重試註冊資源。

問題：在叢集鎖定時，hb_eligible節點發生叢集 TOC:one node assert！

解決方案：在選舉 (election) 逾時時，放棄任何是
hb_eligible，但未傳送投票 (vote) 的節點。

問題：在 cmapplyconf新套件後看不見套件資源。

解決方案：已修改程式碼能在每次變更配置時，重新整理被 cmsnmpd 保留住的叢集資料。

問題：SG11.13版允許線上 cmapplyconf新的EMS資源。

解決方案：未變更程式碼，僅為聲明。

問題：ServiceGuard 管理員活動期間，登錄太多的 cmclconfd 訊息。

解決方案：修正程式碼以查出並略過不支援類型的網路卡。

問題：若在環境中定義 SUCCESS 變數，則 ServiceGuard 安裝作業會失敗。

解決方案：已修正 postinstall 命令集，確保正確地定義它所有的變數。

問題：在無 SG 自動啟動情況下重新開機後，cmsnmpd 不會部署 mib 資訊。

解決方案：已變更程式碼能初始化所有狀態變數，以便在首次啟動 cmsnmpd 時清空字串。

問題：「套件管理員」(Package Manager) 未能及早在叢集組成過程中註冊資源。

解決方案：已變更程式碼，讓「套件程式碼」執行緒在繼續進行其他的初始化之前，會等待 EMS 執行緒完成 EMS 的註冊資源作業。

問題：若未正確地設定 PACKAGE 環境變數，cmmodnet 便會發生奇怪的錯誤而失敗。

解決方案：PACKAGE 環境變數指定一個無法在配置中找到的套件名稱時，便會在syslog 中寫入下列訊息：

cmcld: Unable to lookup package <package name>

亦增強套件控制命令集中的記錄，以警示使用者不要設定 PACKAGE 環境變數。

問題：未記錄在控制命令集中使用 PACKAGE 環境變數。

解決方案：亦增強套件控制命令集中的記錄，以警示使用者不要設定 PACKAGE 環境變數。

問題：當 EMS 監視程式傳回 RM_NOT_READY時，訊息遺失。

解決方案：已變更程式碼以便在監視程式尚未就緒時，會如同它在 A.11.09 版中一樣，顯示 RM_NOT_READY 的「monitor is not ready」訊息。

問題：若密碼長度超過 8 個字元，ServiceGuard 管理員便不會讓 root 使用者登入一個信任的系統。

解決方案：在一個信任的系統內，編碼現在不使用crypt()，取而代之的是允許密碼長度超過 8 個字元的bigcrypt()。