Kdb5_util Load Eating Disk Space?
mllau2002 at yahoo.com
Thu Mar 27 21:17:39 EST 2003
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?
Monica Lau <mllau2002 at yahoo.com> wrote:
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.
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...
More information about the krbdev