Kdb5_util Load Eating Disk Space?

[Monica Lau]

Hi all,
I sent out an email a few weeks ago in regards to the database propagation eating up the disk space in the slave kdc (please see the email below for details).  I tried the latest 1.2.7 Kerberos binaries, but the problem still exists.  After some debugging and tracing, I realized that the kpropd process actually calls "kdb5_util load"  The load function is implemented in the "dump.c" file under the src/kadmin/dbutil directory.  So, after some more debugging with the "load_db" function, I believe the problem lies with the "krb5_db_rename()" function on ~line 2366.  I'm not familiar with the code base, so I don't understand what this function is doing.  All I know is that it causes the disk space to go up by about 4K bytes for every 2-3 kdb5_util loads.  This causes a problem with our systems because after so many propagations, the slave kdc's disk space fills up and crashes.  Does anyone have any clues about this issue?  Is there a website that I can report this bug?  
Thanks,
Monica
 
 Monica Lau <mllau2002 at yahoo.com> wrote:
Hi all,

I have a master kdc and a slave kdc.  In the master kdc, I run a script that executes kprop to propagate the database to the slave every 2 seconds (for testing purposes).  On the slave kdc, I run the "df" command periodically.  I noticed that the disk space percentage usage climbs up slowly.  Eventually, it goes up to 100%, and my slave machine crashes.  I don't understand how/why kprop could cause the disk space in the slave machine to go up because the master database is always the same size.  If I stop the propagation, the disk space in the slave doesn't go down, until I reboot the machine.  

This is sample output from the "df" command:

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock3           14976     13436      1540  90% /

This is sample output from the "mount" command:

/dev/mtdblock3 on / type jffs2 (rw)
/proc on /proc type proc (rw)
none on /dev/pts type devpts (rw)
/dev/ram1 on /tmp type ramfs (rw)
/dev/ram2 on /var type ramfs (rw)

Perhaps, this is a different problem that doesn't have anything to do with kprop, but I only see this happening when I run the kprop script.  Does anyone have any clues about this strange problem?  I'm not familiar with how the kprop process works.  If someone can give me a general overview of the process that occurs when the master database is propagated to the slave kdc, that would be tremenously helpful.  Thanks for your time and help.

Monica



---------------------------------
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online


---------------------------------
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/krbdev/attachments/20030327/af8a16dd/attachment.htm