From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4857 invoked by alias); 25 Jun 2014 20:44:28 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 4836 invoked by uid 89); 25 Jun 2014 20:44:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: smtp5-g21.free.fr Received: from smtp5-g21.free.fr (HELO smtp5-g21.free.fr) (212.27.42.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Jun 2014 20:44:25 +0000 Received: from [192.168.0.13] (unknown [78.224.52.79]) by smtp5-g21.free.fr (Postfix) with ESMTP id 60C1AD4804B; Wed, 25 Jun 2014 22:44:22 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: timeout in LDAP access From: Denis Excoffier In-Reply-To: <20140625101526.GO1803@calimero.vinschen.de> Date: Wed, 25 Jun 2014 20:44:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140617100011.GL23700@calimero.vinschen.de> <20140618083304.GV23700@calimero.vinschen.de> <20140618180102.GA27055@calimero.vinschen.de> <20140623090959.GA1803@calimero.vinschen.de> <20140624155851.GJ1803@calimero.vinschen.de> <20140625101526.GO1803@calimero.vinschen.de> To: cygwin@cygwin.com X-SW-Source: 2014-06/txt/msg00401.txt.bz2 On 2014-06-25 12:15, Corinna Vinschen wrote: >> Stay tuned. I'm rewriting the LDAP access code to perform all critical >> LDAP calls in interruptible threads. The Windows LDAP calls don't >> provide any kind of synchronization, only timeouts. I hoped to get away >> with short timeouts but it seems I hoped in vain. >>=20 >> So the next iteration of this code will not use any timeout other than >> the default LDAP network timeout of 2 minutes, but the calls will be >> interruptible by signals. >>=20 >=20 > No more artificial timeouts, but the LDAP calls will be interruptible by > a signal now. >=20 > Also, if an error occurs during ad enumeration, getpwent/getgrent will > return NULL with errno set accordingly. >=20 > Please test, I did. Again, i instrumented ldap.cc by replacing all debug_printf() calls with system_printf() because my /usr/bin/strace does not work. Again, i tested with =91getent passwd > result=92 and 'db_enum: all=92. I got the following message: [ldap_init] getent 6024 cyg_ldap::connect_non_ssl: ldap_bind(xxxxxx.zzz) 0x= 51 and getent stops after the 376000 users in my own domain. No timeout occurr= ed but the enumeration was stopped by LDAP_SERVER_DOWN (0x51) [the xxxxxx.zzz domain name has been edited here but it was completely new to me, never seen before]. Also, there was a large delay (more than 2 min, say at least 8 minutes) bet= ween the end of output and the end of getent. I got one single system_printf message (see above). More than that, i added system_printf("starting open in domain %W", domain) immediately at the beginning of cyg_ldap::open, and run =91getent passwd=92= now during one minute (wait 60s, then Control-C). I got 1080 =91starting open in domai= n (null)=92 messages on stderr and 1016 normal passwd entries on stdout. The discrepancy 1016 vs 1080 is ok because stdout was not properly flushed out. It seems that - domain is printed as =91(null)=92? Strange - there are as many open() calls as passwd entries in the output? Also stra= nge - EIO (or equivalent) is produced for LDAP_SERVER_DOWN, it probably should = be better if this were not the case? I suppose it will need more testing, but i=92m currently unavailable for te= sts, by the way until Friday 08:00 UTC. Regards, Denis Excoffier.=20 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple