[33521] in Kerberos
Re: Kerberos 1.9.1 locking issues
daemon@ATHENA.MIT.EDU (Dave Steiner)
Wed Jun 29 18:19:10 2011
From: Dave Steiner <steiner.dave@gmail.com>
Date: Wed, 29 Jun 2011 14:39:28 -0700 (PDT)
Message-ID: <91bfcc37-aaba-4199-b38c-0819fd54a5f6@28g2000pry.googlegroups.com>
Mime-Version: 1.0
X-Complaints-To: groups-abuse@google.com
Complaints-To: groups-abuse@google.com
To: kerberos@mit.edu
Cc: steiner@oit.rutgers.edu
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Jun 23, 12:22 am, Greg Hudson <ghud...@MIT.EDU> wrote:
> On Wed, 2011-06-22 at 15:09 -0400, Dave Steiner wrote:
> > Is anyone else seeing these kinds of issues? Are there any
> > recommended ways to fix or help with this?
>
> The database locking discipline is hardcoded and not configurable, but
> if you're able to recompile the code, simply bumping MAX_LOCK_TRIES in
> plugins/kdb/db2/kdb_db2.c to a larger value (from 5 to 15, say) might
> help.
>
> Without further analysis, I'm not sure whether your problem owes to
> changes in 1.9.1 and how much it's just due to increasing load. Changes
> to principals by kadmind requires an exclusive lock on the database, and
> trying five times at 1-second intervals could certainly fail if the KDC
> happened to have the database open for reading at five particular times.
>
> (It would be much more robust if we could get a blocking lock with a
> timeout. Unfortunately, I'm not aware of any good way to do that
> without using alarm signals, which isn't especially nice to do inside a
> library.)
Ok, so I've increased the MAX_LOCK_TRIES to 15 and so far that seems
to have stop this problem except during propagation. I'm still using
the old "dump the data and propagate" method. I assume that if I move
to iprop that this will help with this.
thanks,
ds
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
