From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11268 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Sedich Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [PATCH v2] attempts option not being respected in resolv.conf Date: Sun, 23 Apr 2017 02:42:31 +0000 Message-ID: References: <20170404003657.22843-1-stefan.sedich@gmail.com> <20170422223219.GJ17319@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11402084d73ccc054dcc7158 X-Trace: blaine.gmane.org 1492915381 4928 195.159.176.226 (23 Apr 2017 02:43:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Apr 2017 02:43:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11283-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 23 04:42:52 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d27UA-00012p-Bi for gllmg-musl@m.gmane.org; Sun, 23 Apr 2017 04:42:50 +0200 Original-Received: (qmail 19468 invoked by uid 550); 23 Apr 2017 02:42:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18423 invoked from network); 23 Apr 2017 02:42:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fXcF8uRFIH7eLPVHYmyVXQlbt7rvJiIMgMW8bw87v+E=; b=G7Win73jOJLXiD25VgQ2Y2q46mkw8ARk6buEvavVTDAKt5LW2x+xYOGjeq3Ce5vi2M RwFv443TcRIWK/IVqwMSW3u+bcGiJ5hxuRkkKGPcHPW0KfZH5f6N1/fbLnS4ipFszqPg 09SB9DnwYfOl/sI6QIVvWIQ19ZjA77ERhVq3+p/hMBPefAbgiWNUi1xlkUWmHYqKaXNb XSsz/QoUpGS/tZpKr4PuJS6rzesdbwwScNvHmJGQdXTh4IdhMRml8bpeqYwBdm90yJVn Nod4KtVNFVM/PpKdT3gbbI+2W2oc++rdu4ZHiIwWcOFYdcDFCguu7wJVpaQ6h4kkznqw 47vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fXcF8uRFIH7eLPVHYmyVXQlbt7rvJiIMgMW8bw87v+E=; b=VKNROAMHNK7d16ImjXuaR0uCDxGxzfAzII/bz10RQA6ty3gDttRzPIVA6zTsssuA+0 JyJd7jrPtdKz1/R5dB/uTGJyVWn66ERsSjRAaiewZuGWJT34AD8sVjGXGvUH12UvA2I1 yA77yWYJ+uZ0p1MdCdWIMQzTn/lyoNZxe4H1tuMRp7JsIylvUpcM6GZULGo9JTyVsCIP 1p4b0yI2ZVsVBQvboRsmRZ1rsGDA4/YHD4sOevMgIle2ROcGQ6Tr5Q1cjKtW2L4JCCft QQ1TllYWx3DU55/DL5pL4CahQJdFIEW7pOuQCeqKdkwySDNlD3TZ+imk5KwTu9PT43IG JMEw== X-Gm-Message-State: AN3rC/7c3zuYbLxh98lIYwWQD6PxZzEZzquSf1yBvfJA6F+QPhG/O0eR KqhkPFtnddb/1y9hNfTqFfcKfLYKb/Ml X-Received: by 10.25.141.134 with SMTP id p128mr6735475lfd.60.1492915362150; Sat, 22 Apr 2017 19:42:42 -0700 (PDT) In-Reply-To: <20170422223219.GJ17319@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11268 Archived-At: --001a11402084d73ccc054dcc7158 Content-Type: text/plain; charset=UTF-8 Thanks Rich, I will mull over this and play around with glibc a bit more to see if I can come up with something that gives us that ideal middle ground, I do agree with your initial idea though it sounds like it could behave a little bit closer to glibc but I will dig more and see. Stefan On Sat, Apr 22, 2017 at 3:32 PM Rich Felker wrote: > On Tue, Apr 04, 2017 at 02:08:08AM +0000, Stefan Sedich wrote: > > One thing I have found though is that the way the retry logic works if I > > want to retry ever 1 second for a total of 5 times I need to set it to > > 'options timeout:5 attempts:5', not sure if someone who knows this area > > well can comment but it appears to create a retry_interval based on > > timeout/attempts, which as far as I understand it is different to how it > > works with glibc where I can set timeout:1 attempts:5 and it does as I > > expect. > > The man page documents timeout as "amount of time the resolver will > wait for a response from a remote name server before retrying the > query via a different name server". Since musl does not cycle through > servers, but tries them all concurrently, this definition does not > make sense, so we have to find a reasonable way to interpret the > options, but I agree it might be "wrong" right now. It might be that, > rather than retry_interval being timeout/attempts, retry_interval > should be timeout, and the total timeout should be timeout*attempts. > We really should look at the glibc behavior and see how it scales with > different settings and numbers of nameservers and try to make the > behavior somehow comparable. > > BTW sorry I missed your V2. > > Rich > --001a11402084d73ccc054dcc7158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Rich,

I will mull over this and = play around with glibc a bit more to see if I can come up with something th= at gives us that ideal middle ground, I do agree with your initial idea tho= ugh it sounds like it could behave a little bit closer to glibc but I will = dig more and see.



St= efan

On Sat, Apr= 22, 2017 at 3:32 PM Rich Felker <dal= ias@libc.org> wrote:
On Tue,= Apr 04, 2017 at 02:08:08AM +0000, Stefan Sedich wrote:
> One thing I have found though is that the way the retry logic works if= I
> want to retry ever 1 second for a total of 5 times I need to set it to=
> 'options timeout:5 attempts:5', not sure if someone who knows = this area
> well can comment but it appears to create a retry_interval based on > timeout/attempts, which as far as I understand it is different to how = it
> works with glibc where I can set timeout:1 attempts:5 and it does as I=
> expect.

The man page documents timeout as "amount of time the resolver will wait for a response from a remote name server before retrying the
query via a different name server". Since musl does not cycle through<= br> servers, but tries them all concurrently, this definition does not
make sense, so we have to find a reasonable way to interpret the
options, but I agree it might be "wrong" right now. It might be t= hat,
rather than retry_interval being timeout/attempts, retry_interval
should be timeout, and the total timeout should be timeout*attempts.
We really should look at the glibc behavior and see how it scales with
different settings and numbers of nameservers and try to make the
behavior somehow comparable.

BTW sorry I missed your V2.

Rich
--001a11402084d73ccc054dcc7158--