Kprop Eating Disk Space?
Monica Lau
mllau2002 at yahoo.com
Thu Mar 27 20:53:08 EST 2003
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!!From mllau2002 at yahoo.com Thu Mar 27 21:17:41 2003
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by pch.mit.edu (8.12.8/8.12.8) with ESMTP id h2S2HfFm015115
for <kerberos at PCH.mit.edu>; Thu, 27 Mar 2003 21:17:41 -0500 (EST)
Received: from web20202.mail.yahoo.com (web20202.mail.yahoo.com
[216.136.226.57])h2S2HevX002003
for <kerberos at mit.edu>; Thu, 27 Mar 2003 21:17:40 -0500 (EST)
Message-ID: <20030328021739.45437.qmail at web20202.mail.yahoo.com>
Received: from [63.145.233.34] by web20202.mail.yahoo.com via HTTP;
Thu, 27 Mar 2003 18:17:39 PST
Date: Thu, 27 Mar 2003 18:17:39 -0800 (PST)
From: Monica Lau <mllau2002 at yahoo.com>
To: kerberos at mit.edu
In-Reply-To: <20030311200202.22619.qmail at web20201.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Content-Filtered-By: Mailman/MimeDel 2.1
cc: krbdev at mit.edu
Subject: Kdb5_util Load Eating Disk Space?
X-BeenThere: kerberos at mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Help: <mailto:kerberos-request at mit.edu?subject=help>
List-Post: <mailto:kerberos at mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request at mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request at mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 28 Mar 2003 02:17:41 -0000
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!!From epeisach at MIT.EDU Thu Mar 27 21:34:38 2003
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by pch.mit.edu (8.12.8/8.12.8) with ESMTP id h2S2YcFm015189;
Thu, 27 Mar 2003 21:34:38 -0500 (EST)
Received: from central-city-carrier-station.mit.edu
(CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72])h2S2YbvX004907;
Thu, 27 Mar 2003 21:34:37 -0500 (EST)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU
[18.7.7.71])VAA14475; Thu, 27 Mar 2003 21:34:37 -0500 (EST)
Received: from quick-w20-copy1.mit.edu (QUICK-W20-COPY1.MIT.EDU
[18.187.0.201]) )h2S2YbV3008391;
Thu, 27 Mar 2003 21:34:37 -0500 (EST)
Received: (from epeisach at localhost) by quick-w20-copy1.mit.edu (8.9.3)
id VAA23568; Thu, 27 Mar 2003 21:34:37 -0500 (EST)
Message-Id: <200303280234.VAA23568 at quick-w20-copy1.mit.edu>
To: Monica Lau <mllau2002 at yahoo.com>
In-Reply-To: Your message of "Thu, 27 Mar 2003 18:17:39 PST."
<20030328021739.45437.qmail at web20202.mail.yahoo.com>
Date: Thu, 27 Mar 2003 21:34:37 -0500
From: Ezra Peisach <epeisach at MIT.EDU>
cc: kerberos at MIT.EDU
cc: krbdev at MIT.EDU
Subject: Re: Kdb5_util Load Eating Disk Space?
X-BeenThere: kerberos at mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Help: <mailto:kerberos-request at mit.edu?subject=help>
List-Post: <mailto:kerberos at mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request at mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request at mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 28 Mar 2003 02:34:39 -0000
Is thr ~ line 2366 the krb5_db_rename? That could create a new database
and munge the old one. Why the old one would stick around taking up
space is beyond me...
Ezra
More information about the Kerberos
mailing list