Re: Problems with iprop

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

We'd all like you to give Love as much debugging information as you  
can.  Please continue!

When you run out of time for that, here's a procedure that *should*  
get you to a stable state:

1) shut down all ipropd-slave's.
2) shut down all daemons on the master.
3) on the master do a .../sbin/truncate_log
	You can do a truncate_log --help to list it's arguments.  Unless you  
have your config files in a nonstandard location you shouldn't need any.
4) Restart all master daemons
5) on each slave do:
5a) delete the database and the log files (probably /var/heimdal/ 
{heimdal.db,heimdal.log}, but it depends on the DB library and  
possible overrides in the kdc.conf file)
5b) start ipropd-slave and watch/wait for the new copy of the  
database to finish downloading.  (Alternatively wait for the slaves- 
stats file on the master to show that the slave is up-to-date.)
5c) start the slave kdc.

Incidentally, after the truncate the log file should be 24 bytes  
long, and it should only contain a single no-op command that defines  
the starting version number for the database.

On Jul 27, 2007, at 8:08 AM, Dr A V Le Blanc wrote:

> I wrote:
>> 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?
>
> On Fri, Jul 27, 2007 at 09:48:00AM -0500, Love Hörnquist Åstrand  
> wrote:
>> 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.
>
> Well, this does not appear to be happening.  The looping continues
> until the disk is full.  What log message should appear when the
> master syncs the whole database over?
>
>> 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 ?
>
> Not quite; it seems to loop over a sequence: e.g.,
>
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 1:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 2:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 3:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 4:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 1:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 2:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 3:  
> Entry already exists in database
> Jul 27 06:25:15 zzzzz ipropd-slave[6211]: kadm5_log_replay: 4:  
> Entry already exists in database
>
> and so on endlessly; well almost.
>
> Thanks for your interest.
>
>      -- Owen