csadmind 不启动或在启动过程中崩溃

由于 csadmind 是处理组调度引擎 (Group Scheduling Engine, GSE) 和警报分发引擎的服务，因此，此故障可能是由 GSE 队列或警报队列中的违例条目引起的。

修正方法：

1. 如果 csadmind 未处于运行状态，立即发出 stop-cal 命令。

   保持日历服务器运行可能导致事务日志累积，从而进一步损坏数据库，并可能需要更长时间才能使事务日志文件与数据库一致。

2. 验证是否已停止所有 Calendar Server 进程。

   有关如何验证是否已停止所有进程的说明，参见停止子进程。

3. 通过发出 start-cal -csadmind 命令来尝试再次重新启动 csadmind。

   如果启动成功，通过执行以下步骤确保两个队列运行正常：

   1. 使用 csschedule 检查 GSE 队列。

   2. 使用 dbrig 检查警报队列。

      有关运行 csschedule 和 dbrig 的说明，参见附录 D，Calendar Server 命令行实用程序参考。

4. 如果 csadmind 发生转储故障，分析 pstack。

   如果您在跟踪中发现任何与 GSE 相关的函数（这些函数将带有 GSE 字母），请查看 GSE 队列中的第一个条目和引用的事件数据库中的条目。通常情况下，GSE 条目中引用的事件就是违例条目。要解决此问题，请执行以下步骤：

   1. 使用 csschedule 删除 GSE 条目。

   2. 使用 cscomponents 从数据库中删除违例事件。

      有关运行 csschedule 和 cscomponents 的说明，参见附录 D，Calendar Server 命令行实用程序参考。

5. 如果条目未损坏，则可能是日历服务器无法处理的特殊故障。

   请执行以下步骤：

   1. 拍下损坏的数据库的日历环境快照，并与客户支持联系。

      要创建环境备份，请执行以下步骤：

      1. 使用 db_checkpoint 实用程序（位于：

         cal-svr-base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint）

      2. 运行 db_archive -s。

         使用 -s 选项确定所有数据库文件，并将其复制到可移动介质（例如 CD、DVD 或磁带）中。

      3. 运行 db_archive -l。

         使用 -l 选项确定所有日志文件，并将未应用的日志文件复制到可移动介质设备中。

   2. 为避免服务中断，请将日历数据库临时置入只读状态，并恢复为紧急备份副本。

      • 将日历数据库临时置入只读状态，以防出现添加、修改或删除事务。最终用户尝试添加、修改或删除任何日历数据时，将收到错误消息。数据库处于只读模式时，用于添加、修改或删除日历事件和待办事项的管理员工具也将不起作用。

        要将日历数据库置入只读模式，编辑 ics.conf 文件，按如下所示将指定参数设置为 "yes"：

        caldb.berkeleydb.readonly=”yes”

      • 按照22.5.8 恢复自动备份副本中的说明，恢复为紧急备份副本。

        配置并启用 csstored 之后，在几分钟的更新后即可使用紧急备份。还应当始终验证紧急备份副本以确保其未损坏。（运行 db_verify。）

6. 如果所有修复操作均失败，请执行转储和重新装入过程以查看是否可以抢修数据库。

   22.5.7 使用转储和装入过程来恢复日历数据库中介绍了此过程。