此版本的修补软件和已作的修复

问题和解决方案

问题：当 RUN_SCRIPT_TIMEOUT 的值超过 4294 时将无法运行。

解决方案： ServiceGaurd 手册的 11.12 版本中将记录此参数及其它程序包参数的可采用的值。

问题：本地切换以后，由于连续的、意外的成员与协作节点之间的 TCP 连接的损坏，导致 ServiceGuard 群集的执行再三失败。最终，安全时间过期导致整个群集的控制转移 (TOC)。

解决方案：如果此受害节点所处的状态确定，则现在此节点将重新建立意外丢失的连接。

问题：启动程序包时，程序包控制脚本尝试在指定的装载点上的装载控制脚本中指定的所有逻辑卷。如果这些装载点之一正忙，导致控制脚本中的装载操作失败，程序包将无法启动。

解决方案：程序包控制脚本现已增强为允许客户为防止装载失败而指定重试次数来重试装载操作。将新的配置变量 FS_MOUNT_RETRY_COUNT 添加到程序包控制脚本，以便可以选择地设置重试安装操作的次数。每次重试过程中，使用 fuser -k 都可删除任何正在使用装载点的进程。

问题：用户无法定义共享内存附加地址用于 udlm 客户机。

解决方案： 现在已给用户提供了一种指定附加地址的共享内存的方法。

问题：此代码不处理定时窗口，将交易异常中止发送到 cmcld 以后，执行配置操作的客户机将终止。

解决方案：已添加更好地管理客户机进程丢失问题的代码。

问题： OPS 8.0.5 不能写入异步的 I/O 磁盘设备。

解决方案：可从 Oracle 8.0.5 的修补软件中得到永久修复。

问题：群集节点上 Oracle 数据库的并行执行导致所有群集节点上的控制转移紧跟 cmcld 守候进程核心之后。

解决方案：已更改生成交易标识符的算法。旧的算法使用“自从上次重新引导的时钟周期”可在同一时钟周期内生成同样的标识符。新的算法使用计数器，即每生成一个新的标识符，此计数器的值就增加 1。

问题：不能分配足够的缓冲区存储 X.25 接口的 MAC 地址，此接口有 20 个字节长，这将导致程序堆栈无意中被覆盖。

解决方案：增加缓冲区的大小，使其足够存储任何接口（包括 X.25）的 MAC 地址，。

问题：虽然 LAN 故障切换运行正确，但是进行故障切换时，在驱动程序重置过程中仍然存在 DLPI 反回错误的窗口。由此产生的错误消息出现在系统日志中。

解决方案：日志级别已经更改，因此系统日志中不再出现这些错误消息。

问题：代码不区分常规磁盘与 DVD-ROM 磁盘。

解决方案：现在，在设备检测中可忽略 DVD-ROM 磁盘。

问题：由于内部数据结构的不一致性导致设备名称查找的失败。

解决方案：已更改代码，可以存储和查找与数据结构一致的设备名称。

问题： swremove 暂停程序包并删除群集配置。

解决方案：将新文件 CM-CORE.checkremove 添加到在使用 swremove 期间使用的脚本。此文件检查以确认允许执行 swremove 之前是否已暂停群集。

问题：在某些情况下，仍旧运行的例程和节点不能识别其他节点的关闭。影子进程正再等待 lamport 时钟状态变得正常，但是 DLM 认为它的状态已经正常。

解决方案：已经修复了在 DLM 的重新配置过程中不能正确更新时钟值的分布式时钟中的缺陷。

问题：MC/ServiceGuard Advanced Tape Services 的 stquerycl 命令不识别某些磁带程序库机器人技术（自动变换器）。

解决方案：将 C7200-8000 和 A5617A 标识符添加到 Advanced Tape Services 标识文件 (/etc/cmcluster/sharedtape/ats_tapelibs) 中。

问题：当记录接口更改成 A.11.09 时，不能再将 log_level 参数传递到 cf_find_config() 中。

解决方案：已经修改代码，现在可正确地传递 log_level 参数。已在 11.09 和 11.12 两个版本加入修复的内容。

问题：如果在群集运行时尝试 ServiceGuard 的 swremove 命令，则会暂停群集且使配置文件 (cmclconfig) 无效。

解决方案：在 swremove 的分析阶段已经添加了新脚本的内容，可验证继续执行操作前是否已暂停群集。如果没有暂停群集，那么 swremove 将显示错误消息并异常中止。

问题：如果将 NODE_TIMEOUT > 设置为大于 30 秒，则在暂停操作过程中群集重组所需要的时间将超过 30 秒。命令型客户机代码允许群集重组的硬编码限制为 30 秒。当群集重组所需要的时间超过 30 秒时就会失败，并报告上述错误消息。

解决方案：将硬编码的 30 秒限制替换为与 NODE_TIMEOUT 成比例的变量。

问题：虽然将 NODE_TIMEOUT 缺省设置为 2 秒会加快群集重组，但是也可能导致无法保证的重组结果和控制转移。对那些经常遇到短暂的 CPU 饥渴或网络拥塞事件的系统来说，此缺省值可能太武断。

解决方案：将文本添加到 cmquerycl(1m)“联机帮助”页和群集配置文件注释中，表明 2 秒的缺省超时时间会产生最快的群集重组速度，但是也可能导致无法保证的控制转移。建议将超时设置设置为 5 至 8 秒。

问题：在双端口和四端口的硬件中，经常有一个或多个端口闲置，因此可忽略这些端口。但是，配置守候进程 cmclconfd 不忽略这些无用的端口，相反，此守候进程会将它们作为严重级别为 0 的错误记录下来。

解决方案：将这类情况的记录级别增加到 3，这样这种情况下不再出现严重级别为 0 的错误。

问题：如果链接列表中的已个元素被去掉，则代码将不会遍历包含群集内节点信息的整个链接列表。

解决方案：现在，从链接列表中去掉当前元素之前代码会记忆下一个元素。

问题：如果在查看本地的 /.rhosts 文件之前已通过 NIS 检查了主机名/用户名的安全性，则带 -C 选项的 cmcheckconf 和 cmapplyconf 命令将无法检测群集中网络的连通性。

解决方案：为这个问题现已修复，通过使用 /etc/cmcluster/cmclnodelist 文件用于安全性检查，这样可避免由访问 NIS 服务器引起的较长时间的延迟。

问题：预先没有检查程序包名称和服务名称。因此，当将这些名称存储到 CDB 中时，‘/’字符就会导致 CDB 问题。

解决方案：已添加代码，以预先使群集名称、程序包名称以及服务名称有效。

问题： /tmp 已满导致 Oracle 8.0.5 中发生控制转移。

解决方案：通过在群集 ASCII 配置文件中将目录路径添加到 GMS_LOCATION 字符串之后，则此目录路径成为可配置的。

问题：由于多种原因，系统管理员有时需要终止系统进程。cmlvmd 进程并没有因此而屏蔽信号。因此，如果管理员错误地将终止信号发送给 cmlvmd，此进程将终止。这接下来又会导致 cmcld 重新引导或控制转移系统。

解决方案：已将其他信号处理方法添加到 cmlvmd。

问题：在 ServiceGuard 网络探测区域没有可用的自动的重试机制。因此，当由于流量忙几个网络接口不能从其他接口获得探测消息时，ServiceGuard 配置命令就过早地断定这些接口之间存在不同的网络连接。

解决方案：已实施重试机制，这样将重新传送丢失的探测消息，直到它们的对等点接收到这些消息或直到达到最大的重试次数。

问题：给存储未配置的 DLSAP 地址的 ASCII 表示分配的缓冲区不够大。这样就导致堆栈崩溃问题。

解决方案：缓冲区的大小已经增加为可以容下任何接口类型的最大的 DLSAP 地址。

问题： 如果 cmcld 遇到意外的系统调用中断，它将遇到断言核心“Assertion failed:inp->state == CL_NODE_ADDING.”

解决方案：当此代码返回 EINTR 的时候，它将重试连结调用。

问题： 如果 NODE_TIMEOUT 超过了 30 秒，cmhaltcl 命令将无法地暂停最后一个节点，同时显示错误消息：“cmhaltcl :Unable to connect to daemon”

解决方案：将硬编码的 30 秒限制替换为与 NODE_TIMEOUT 成比例的变量。

问题：PHSS_21107 中的修复引入了新文件的创建。对于 HP-UX，此文件没有任何意义，不应被创建。

解决方案：不再创建此文件。

问题： cmrunnode 不能在 /init.d/cmcluster 中重试。

解决方案：cmrunnode 命令进行检查以查看是否有在线的群集。如果有，此命令将启动虚事务以阻止其他任何客户机更改 CDB。一旦群集完成重组，cmrunnode 命令将启动 cmcld 然后异常中止虚事务。

问题：如果在另一个节点上执行 OPS 程序包并启动 OPS 例程，则 cmrunnode 将失败。

解决方案：cmrunnode 命令进行检查以查看此群集是否在线。如果有，此命令将启动虚事务。这将防止其它客户机更改 CDB。一旦群集完成重组，cmrrunnode 命令将启动 cmcld 然后异常中止虚事务。

问题：cmapplyconf 命令在错误状态下退出，即使在发现错误时。这将造成某类群集的组成错误。

解决方案： 如果 cmapplyconf 发现心跳子网错配的网络掩码，它将正常地异常中止。

问题：“DLPI 缓冲区”崩溃。

解决方案：已添加有关接收到的消息的校验和和大小的检查。记录问题之后，即减少崩溃的缓冲区。发送前，添加代码以检查消息的大小。

问题：暂停操作过程中，cmhaltnode 命令锁定配置数据库以防止节点暂停时的更改。通过创建与远程节点上的配置守候进程的连接并发送消息请求挂起该锁，可以完成锁定。暂停过程中，群集管理程序 (cmcld) 总是将节点恢复到它的原始配置。如果主网上的节点遇到 NIC 故障而群集管理程序已切换到备用 NIC，则暂停过程中，主 IP 将切换回有故障的 NIC。这可有效地造成到节点的网络连接的丢失。如果 cmhaltnode 已经在此节点上运行，则它将丢失与配置守候进程间的连接并且不能解锁配置数据库。这会导致配置数据库处于锁定状态 2 个小时（缺省的网络保持活动状态的超时值）。

解决方案：y已更改锁定算法，仅当节点为活动的群集成员时（这是防止配置更改的充分条件），锁定本地节点。

问题：在群集组织的静止周期中，当新节点加入时，群集将把此节点计入活动节点的最终数目。如果此时现有的节点已终止，则群集开始重组，并获得活动节点的最终数目的定额。但是因为我们只应接受最后群集中老成员的表决，所以我们活动节点的最终数目过大。

解决方案：当活动节点的最终数目包括不允许表决的节点时，设置一个可以表明的标志。计算定额时解释此标志。

问题：程序包控制脚本中释放忙装载点的功能不处理任何情况下正确传递给其的输入参数。只有遇到下列情况才会发生此问题：

解决方案：代码确保装载点选项已经正确地通过。

问题：群集守候进程 cmcld 异常中止，并报告系统日志消息“This node did not reply to CDB request。”

解决方案：这是由写磁盘过程中阻塞的 CDB 事务造成的。已修改此代码，使其在写磁盘过程中不再阻塞。

问题：将可配置的参数 MANUAL_START_TIMEOUT 记录在 cmquerycl “联机帮助”页，但是不能通过 cmquerycl 命令在 ASCII 文件中生成此参数。当将此参数添加到 ASCII 文件，cmcheckconf 和 cmapplyconf 命令也支持此参数。

解决方案： 从 ServiceGuard 中删除 MANUAL_START_TIMEOUT 的支持。如果在群集 ASCII 文件中指定 MANUAL_START_TIMEOUT，则 cmcheckconf 命令失败并报告错误消息。此参数也从 cmquerycl“联机帮助”页删除。

问题：在双心跳配置中，当通过第二条连接发送的消息要比通过第一条连接发送的消息到达的早时，ServiceGuard 守候进程 (cmcld) 将发生核心转储，并报告“out of order message”的错误。

解决方案：已更改代码检查这种情况。

问题：配置双群集锁时，如果获得第一个群集锁的请求失败，则重启群集成员关系选择。如果因为两个锁磁盘中的一个或另一个停止运行而导致请求失败，继续重启此选择，直至安全时间耗尽导致发生群集控制转移。

解决方案：已经更改双群集锁定，这样 1) 如果第一个双锁在锁请求时失败，ServiceGuard 将继续运行并尝试第二个双锁；2) 如果第一个双锁请求成功而第二个双锁在锁请求时失败，ServiceGuard 会假定请求群集锁成功，并使用群集成员关系协议继续运行。

问题：没有关闭 KEPD 文件描述符（控制台），这将潜伏着资源泄漏的危险。

解决方案：现已关闭文件描述符。

问题：当 putmsg() 或 getmsg() 返回错误时，ServiceGuard 不能正确处理 EINTR 代码。

解决方案：已更改代码，在系统调用返回 EINTR 时进行重试。

问题：在内部，ServiceGuard 遍历设备树，然后在这些设备标识符的基础上建立设备名称。SG 接着对这些它所建立的设备名称检查群集锁磁盘 PV 字符串。由于它建立的这些名称实际上不是真实的设备名称，所以检查失败。

解决方案：现在通过 HP-UX 程序库例行程序 ftw() 在系统上使用真实的设备名称建立设备树。然后使用这些名称，与群集 ASCII 文件中的名称相比较。

问题：当 ServiceGuard 守候进程 cmcld 尝试建立心跳连接时，套接字调用返回错误 EAGAIN，导致 cmcld 异常中止。

解决方案： 现在无论何时返回错误 EAGAIN、ENOBUFS 和 ENOSR 时，cmcld 将重试套接字调用。

问题：对于 cmcheckconf 和 cmapplyconf需要其他的 NODE_TIMEOUT 参数范围检查以消除混乱。NODE_TIMEOUT 参数缺省为 2000000 （2 秒）。此缺省设置会产生最快的群集重组速度。但是，由于瞬时系统挂起或网络负载尖峰，所以缺省值的使用会增加伪重组的潜在性。

解决方案：已添加了新的算法来检查 NODE_TIMEOUT 的值是在建议的范围内还是在发出 cmcheckconf 和 cmapplyconf 命令时。如果不是，就会以“NOTE”形式发出警告说明建议的范围。

问题：系统日志中出现过多的“事务正在进行中”的消息，客户将其解释为一个问题。

解决方案：已经在 ServiceGuard OPS Edition 中将此消息的日志级别更改为 2，这样在正常的环境下此消息不能写入系统日志。

问题：ServiceGuard 守候进程异常中止，因为 cmlvmd 不能按时启动，但是 cmlvmd 仍在运行。

解决方案：LVM 守候进程启动时出现的定时窗口已关闭。

问题：由于某个插座 ioctl 返回 EINTR （中断系统调用)错误代码，所以 cmmodnet 命令失败，调用此插座 ioctl 可以添加或删除 IP 地址。虽然这是瞬时错误，但是 ServiceGuard 不重试此 ioctl。因此，命令退出并报告错误。

解决方案：实施重试机制，允许在返回 EINTR 时，cmmodnet 命令可重复调用此类 ioctl。

问题： cmquerycl、cmcheckconf 和 cmapplyconf 在不一致的 VG 配置中显示错误消息。

解决方案：已修改软件，这样如果不一致的 VG 配置不严重并且命令完成成功，cmquerycl、cmcheckconf 和 cmapplyconf 显示警告消息而不是错误消息。

问题：暂停节点时，cmcld 关闭 cmlogd 守候进程以便从容地完成服务。此操作完成的前提是假定将所有最后的消息直接发送到系统日志。但是，确实存在一些已经发送到 cmlogd 和正等待写入系统日志的重要的网络日志消息。因此，一旦退出 cmlogd 服务，这些消息就再也不能写入系统日志。

解决方案：现在，暂停节点时不关闭 cmlogd 守候进程。相反，当此守候进程检测到 cmcld 已经退出时，它将从容地终止。

问题：操作系统充分行使功能之前，转换实用程序的执行导致 ServiceGuard 的二进制文件转换问题。

解决方案：运行二进制文件转换实用程序的 ServiceGuard 配置脚本由 swconfig 重新运行。这样就可以完成转换。

问题：执行 ServiceGuard 启动脚本时，inetd 守候进程并不总是已完成初始化。因此，inetd 不能启动可以启动群集的 cmclconfd。

解决方案：修改脚本 cmcluster.init 重试 cmrunnode -v 命令。

问题：对 cmrunnode 命令的预先修复涉及到将其他锁定添加到节点启动进程。此锁定可有效地阻止两个同时使用的 cmrunnode 调用一起取得成功。

解决方案：将重试机制添加到系统启动脚本 /sbin/init.d/cmcluster。

问题：命令 stdeleteconf 不检查 ServiceGuard 的混合修订版。

解决方案： 当群集中存在 ServiceGuard 的混合修订版时，不允许使用 stdeleteconf。

问题：支持联机 I/O 操作的新的 PCI LAN 驱动程序在联机更换过程中将卡的 MIB 统计数据重置为 0。此行为给 ServiceGuard 的网络管理器创建逻辑问题，这样它可在完全恢复链接之前声明已更换的卡的恢复。

解决方案：已经更改用来确定故障的网卡恢复的算法，以支持新的驱动程序行为。

问题：多个“联机帮助”页包含拼写错误。

解决方案：在“联机帮助”页上运行拼写检查程序 ispell。

问题：当尝试打印负的错误编号时，函数 cl_strerror 异常中止。

解决方案：修改 cl_strerror 函数，使其可将错误打印为负编号。

问题：消息不包含足够的信息。

解决方案：将硬件信息添加到现有的消息。添加另一个数据验证以减少可能的原因窗口。

问题：当联机 ServiceGuard 节点发出配置操作时，它首先生成事务标识符，所有节点都可使用此表识符验证此项操作。此事务标识符在群集内必须是唯一的。事务标识符中用来将节点具体化的一个组件，在由 uname(2) 返回时是指机器标识符编号。在 Superdome 文档柜内，所有分区返回同样的机器标识符，这样，事务标识符就不再是唯一的。

解决方案：已经更改用来生成事务标识符的算法，这样此算法不再依赖机器标识符，而使其成为唯一的标识符。

问题：在群集重组协议中存在着非常小的漏洞，此漏洞使得单节点群集（禁用安全定时器）在重新启用安全定时器之前可尝试重组双节点群集。如果将来故障的正确组合紧随其后，则单个节点将处于不断尝试群集重组的状态中。

解决方案：已经修改协议，这样在允许群集重组继续进行之前必须启用安全定时器。

问题：如果 begin_trans 报告另一项 cdb 事务正在进行中，则 cmgmsd 在没有任何延迟的情况下重试 begin_trans 就会导致机器挂起。过多的 begin_trans 请求会适时导致 cmcld 占用重要的 CPU 周期来响应这些请求。在单 CPU L 系列机器中，TOP 报告 cmcld 可以使用 40% 的 CPU 时间，cmgmsd 可以使用 CPU 另外的 20%。因为这两个进程都作为比常规进程（类似 telnetd）优先级高的进程正在运行，所以产生饥渴问题。

解决方案：更改是减少 cmgmsd 重试 begin_trans 的比例。

问题：在配置事务的提交阶段，事务线程拥塞，等待 cmclconfd 返回消息。

解决方案：衍生线程以管理与 cmclconfd 的通信。

问题：在某些情况下，ogms 守候进程异常中止，导致节点发生控制转移。

解决方案：可从 Oracle 获得的 ogms 专用版本不会异常中止。要获得 ogms 的专用版本，请与 Oracle 联系并参考 bug# 1107981。