Since csadmind is the service that handles both the group scheduling engine (GSE) and the alarm dispatch engine, this could have been caused by offending entries in the GSE queue or the alarm queue.
If csadmind is not running, issue the stop-cal command immediately.
Leaving calendar server running could cause transaction logs to accumulate, which could further corrupt the database, and could take much longer to reconcile the transaction log files to the database.
Verify that all Calendar Server processes are stopped.
For instructions on how to verify that all processes are stopped, see To Stop Child Processes.
Try restarting csadmind again by issuing the start-cal -csadmind command.
If it starts successfully, make sure the two queues are functioning by performing the following steps:
Checking the GSE queue using csschedule.
Checking the alarm queue using dbrig.
For instructions on running csschedule and dbrig, see Appendix D, Calendar Server Command-Line Utilities Reference.
If csadmind crashes with a dump, analyze the pstack.
If you notice any GSE related functions in the trace (they will have the letters GSE in them), look at the first entry in the GSE queue and the referenced entry in the events database. Most of the time, the event referred to in the GSE entry is the offending entry. To fix this problem:
Remove the GSE entry using csschedule.
Remove the offending event from the database using cscomponents.
For instructions on running csschedule and cscomponents, see Appendix D, Calendar Server Command-Line Utilities Reference.
If the entries are not corrupted, then it could be a special case that the calendar server could not handle.
Take the following steps:
Take a calendar environment snapshot of the corrupted database, and contact customer support.
To create an environmental backup:
Use the db_checkpoint utility found at:
Run db_archive -s.
Use the -s option to identify all the database files and copy them to a removable medium, such as CD, or DVD, or tape.
Run db_archive -l.
Use the -l option to identify all the log files and copy unapplied log files to a removable-medium device.
To avoid service interruptions, place your calendar database into a read-only state temporarily, and revert to a hot backup copy.
Placing your calendar database into a read-only state temporarily prevents any add, modify or delete transactions from taking place. End users will get an error message when they try to add, modify or delete any calendar data. Administrator tools that add, modify or delete calendar events and todos also will not work while the database is in read-only mode.
To put your calendar database in read-only mode, edit the ics.conf file and set the following parameter to “yes”, as shown:
Revert to a hot backup copy, using the instructions found in 22.5.8 Restoring an Automatic Backup Copy.
With csstored configured and enabled, a hot backup is available that should be within minutes of being uptodate. You should always verify your hot backup copy to make sure it is not corrupt also. (Run db_verify.)
If all else fails, perform the dump and reload procedure to see if it can salvage the database.
This procedure is described in 22.5.7 Using the Dump and Load Procedure to Recover a Calendar Database.