Return-Path: Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (Postfix) with ESMTP id 99E633E692; Tue, 25 Sep 2012 17:15:17 -0400 (EDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id q8PLFGdr018113; Tue, 25 Sep 2012 17:15:16 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id q8PLAHQw017392 for ; Tue, 25 Sep 2012 17:10:17 -0400 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id q8PL9ams008344 for ; Tue, 25 Sep 2012 17:10:17 -0400 X-Auditid: 1209190f-b7f636d00000095b-d0-50621db8decf Authentication-Results: symauth.service.identifier Received: from homiemail-a36.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.E3.02395.9BD12605; Tue, 25 Sep 2012 17:10:17 -0400 (EDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 8AEE6778071 for ; Tue, 25 Sep 2012 14:10:16 -0700 (PDT) Dkim-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=HL2GRncSAiP5FnHM62YXSmSFpuI=; b=tpg7GzVK+tl GxMOyeNGdtLH1SSuGJNbDFQG6VOtv52DgL0M1j9MG1SZLm68Veynhjsbc19E08QU LwYsStJgfTmfS4ZBJM2jUAHFCN6o50EiDNxp8Tvk7G0VyIdAaPcGKoDD3NtQfGeo 2JwVFoh9nEh/1shuCa/f1aDPz2Q3wfiA= Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 6FFBA77805F for ; Tue, 25 Sep 2012 14:10:16 -0700 (PDT) Received: by padbi5 with SMTP id bi5so2571473pad.36 for ; Tue, 25 Sep 2012 14:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.133 with SMTP id c5mr44146515paw.24.1348607415994; Tue, 25 Sep 2012 14:10:15 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 25 Sep 2012 14:10:15 -0700 (PDT) Date: Tue, 25 Sep 2012 16:10:15 -0500 Message-ID: Subject: iprop can block for extended periods due to UPDATE_BUSY From: Nico Williams To: krb5-bugs@mit.edu Content-Type: text/plain; charset=UTF-8 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRWlGSWpSXmKPExsVyIbElWHenbFKAwc/pchYND4+zOzB6NJ05 yhzAGMVlk5Kak1mWWqRvl8CVcfboYpaCRv6K9m9dbA2MPdxdjJwcEgImEpduHWAEsRkFjCR2 n3vFChEXk7hwbz1bFyMXh5DAI0aJo/f/s0I4Zxgl2ne/AcuwCLxnkri8aR07ROYhk8T2XW+Z QPqFBKolVh3eBGbzCghKnJz5hKWLkQMoXiDRfKYGosRLYkHrRnYQm0VAVeJP9xQWiPIAidbZ a8FahQUcJO5/PskE0somoC2xeZsiSFhEQFTi5d9jYBOZBdQl1s8TmsAoOAvJrlkImQWMTKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0TfRyM0v0UlNKNzECA1KIU5J/B+O3g0qHGAU4GJV4eA88 TwwQYk0sK67MPcQoycGkJMr7SCopQIgvKT+lMiOxOCO+qDQntfgQowQHs5IIrzFIOW9KYmVV alE+TEqag0VJnPdqyk1/IYH0xJLU7NTUgtQimCwTB/shRhkODiUJXhZgDAoJFqWmp1akZeaU IKvhBBFcIGt4gNYckgYq5C0uSMwtzkyHKDrFaMzx8eSCB4wclz4ufsAoxJKXn5cqJc4rAzJT AKQ0ozQPbiQs0VxilJUS5mVkYGAQ4gG6CRgUqPKvGMWBwSDM+0UGaApPZl4J3L5XQKcwAZ3C vycO5JSSRISUVANj7i4TvXX3j754+0VTZLbxn22+3ZHeN2+vONF2/7Oog8WrtC2L35v7rig4 6mZeXqRxt+L38v4F0VUJs6KWCey5zrPUfY+9TGm+d86KGYd/3j7o46F09rSQ1snS//wrjFiC bsjKXnm+8234Rs2cBW1OcXO+ROg+URX9uX7lcrlbvA5lS7y5lbseKbEUZyQaajEXFScCAAG8 OWwvAwAA X-Mailman-Approved-At: Tue, 25 Sep 2012 17:15:15 -0400 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu Content-Length: 1873 Currently kadmind allows slaves to poll for updates as often as they like, but not within 10s of the last update. This means that iprop will appear to fail to synchronize the KDC at any site whose master KDC processes at least one write transaction every 10 seconds consistently. The original intention must have been to throttle iprop clients (slave KDCs) that poll too often. But UPDATE_BUSY as implemented is not that, and implementing a throttle would be difficult (requires keeping state in a table) and mostly useless (admins can manage their poll timers just fine without a throttle in kadmind). The simplest fix would be to remove all semblance of UPDATE_BUSY handling in kadmind: diff --git a/src/lib/kdb/kdb_log.c b/src/lib/kdb/kdb_log.c index dc994dd..b800fa6 100644 --- a/src/lib/kdb/kdb_log.c +++ b/src/lib/kdb/kdb_log.c @@ -726,10 +726,9 @@ ulog_get_entries(krb5_context context, /* input - krb5 lib config */ XDR xdrs; kdb_ent_header_t *indx_log; kdb_incr_update_t *upd; - uint_t indx, count, tdiff; + uint_t indx, count; uint32_t sno; krb5_error_code retval; - struct timeval timestamp; kdb_log_context *log_ctx; kdb_hlog_t *ulog = NULL; uint32_t ulogentries; @@ -750,15 +749,6 @@ ulog_get_entries(krb5_context context, /* input - krb5 lib config */ return (KRB5_LOG_CORRUPT); } - gettimeofday(×tamp, NULL); - - tdiff = timestamp.tv_sec - ulog->kdb_last_time.seconds; - if (tdiff <= ULOG_IDLE_TIME) { - ulog_handle->ret = UPDATE_BUSY; - (void) ulog_lock(context, KRB5_LOCKMODE_UNLOCK); - return (0); - } - /* * We need to lock out other processes here, such as kadmin.local, * since we are looking at the last_sno and looking up updates. So