Propagation

Monitoring Propagation

connect delay is seconds sec

[hostname of peer] Can’t connect to subscriber to propagate principal database information [hostname of peer] could not get service ticket [hostname of peer] full_dump failed

[hostname of peer] not enough memory to allocate work buffer

Not enough free system resources to run or start the propagation system.

Propagation system aborting.

Not enough system resources free to read from propagation queue.

Propagation system aborting.

Out of memory

Monitoring Propagation Queue Files

When database changes occur on the primary server, the modifications are recorded in the propagation queue file, prop_q. The kpropd daemon reads the prop_q file, which lists all principals that have changed since the last propagation cycle. At the end of a successful propagation cycle, all security servers have up-to-date principal databases.

To indicate successful propagation, kpropd creates a prop_hostname_ok file, a zero-length file, where the hostname is the name of the security server being propagated to. If the propagation failed, a prop_hostname file is created and all the un-propagated changes are saved to the file. After propagation of these changes to all of the secondary servers succeeds, the contents of the queue file, prop_hostname, are deleted. If neither the prop_hostname or the prop_hostname_ok file exists for a specific host, then kpropd conducts a full dump of the primary database to the secondary server that is missing a queue file.

Monitoring for Old File Date and Large File Size

In rare cases, a propagation failure or stall may occur without any indication of error in the syslog messages. Additional monitoring measures can be taken to check for proper operation of the propagation system. The propagation queue files can be monitored for unusual characteristics, such as old file creation date or large file size. Under normal conditions these files are created, deleted, and appended many

230

Chapter 7