Re: Problems with iprop

[Love Hörnquist Åstrand <lha@kth.se>]

> Yesterday I followed Henry Hotz's advice and stopped the master,
> zeroed the log, stopped the clients, zeroed the log, and copied
> the database across to be sure it was the same.  This morning already
> one slave server had over 87000 kadm5_log_replay error messages in
> an hour and a half, and full disks on the slave servers.  I moved
> back to the Debian 0.7.2.dfsg.1-10, but it does not seem to have
> helped.  Should I try dumping the master database and reloading
> it from the dump?

You don't need to copy over the database to the slaves, the master will
sync over the whole database if the entires are out of sync and the
log entries are out of sync enough that it can't do a sync.

Applying FORYOU messages a database thats already in sync is probably
a very bad thing. What I can't understand is why the client is  
looping and
logging several.

The version number (2469) in your example is always the same ?

      ipropd-slave[8760]: kadm5_log_replay: 2469: Entry already  
exists in database

> Or should I just give up on iprop for the time being?
>
> Incidentally, Henry Hotz mentioned the truncate_log and iprop-log
> commands for the 0.7 and 0.8 servers respectively.  I do have the
> truncate_log command in 0.7, but there's no man page, and it's
> not in the info file.  Are there any guidelines for using it?

iprop-log is the truncate_log, replay_log, dump_log folded together.
so the manpage for iprop-log manpages applies to the separate commands.

Love