Archive Index This month's Index

Subject: Re: gethostbyname reload resolv.conf values

Re: gethostbyname reload resolv.conf values

From: Nayanā Topolsky <nayana.topolsky_at_zoho.com>
Date: Wed, 28 Aug 2019 17:10:29 +0200

Ok so the two things that maintainers disliked were
1, performance load because of periodical checks
2, And change of default behavior for toolbox users (which use all kinds
of custom options)

I believe the performance issue is solved by checking just stat of the
file instead of full ares_init call (possibly) each second.
This /etc/resolv.conf stat() idea is already implemented in glibc:
bug thread - https://sourceware.org/bugzilla/show_bug.cgi?id=984
part of patch checking stat:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blobdiff;f=resolv/resolv_conf.c;h=9ef59240ebc57a70c22c369ff29e79c68c427225;hp=dd665239926cbac772ef5bef757575580d22ccb5;hb=aef16cc8a4c670036d45590877d411a97f01e0cd;hpb=a1c4eb8794e789b5055d7ceb13b2b3231abf5e26

If glibc has this, why c-ares would not like to have it?

But current merge blocker was that the solution was "too specific" -
because I dealt only with Linux (and OSX) and not with Windows etc.

Maybe I could come up with more robust solution to reload really
everything when resolv.conf is changed
And then additionaly do some similar checks for windows (probably just
blindly) - loading registers and checking difference.

And then it can be made some kind of c-ares option - disabled for c-ares
by default
and in curl use case enabled internaly by curl for c-ares channel.

But now it just looks like this effort will slowly die as nobody really
wants it and it will pop up every decade :D

My patch shall be used on thousands of devices, but probably this
strange use case happens only very specificly.

Dňa 28. 8. 2019 o 5:31 Dima Tisnek napísal(a):
> It's been 9 years, and frankly I don't remember very well.
> https://c-ares.cool.haxx.narkive.com/HQegCCf6/ares-reinit-patch is the archive.
>
> re: when to cancel outstanding requests.
> it's a good question to which I don't have an answer.
> on one hand, if `resolv.conf` was changed because the device moved to
> a new network, it's unreasonable to expect the old request to succeed.
> on the other, if only a small part of `resolv.conf` was changed, it's
> odd to break user's requests.
>
> I am somewhat concerned by the idea of reloading only a part of
> resolv.conf; I feel that will only work in basic. Maybe that's worth
> is to start. Ideally maintainer would weigh in on this.
>
> On Mon, 26 Aug 2019 at 17:20, Nayanā Topolsky <nayana.topolsky_at_zoho.com> wrote:
>> Hi Dima,
>>
>> so, you mean that when going from wifi to wifi there might be some pending request
>> and for that, one needs to call ares_cancel?
>> I thought that ares__destroy_servers_state would be enough.
>>
>> Also I tried to counter-reinit everything that is initialized in init_by_resolv_conf
>> including domain and nameserver.
>> In my patch I am clearing all channel values and call init_by_resolv_conf once again so every information in
>> /etc/resolv.conf shall end up in channel struct values.
>>
>> Did I missed something?
>> This is for instance clearing of domains:
>> https://github.com/nayana-sue/c-ares/commit/696a1d59be106520a0471348caa469b03aa477ae#diff-6c5528d5eccbe836842006e4f0cb89baR1900
>>
>> Of course your patch is much more robust because you also load the parameters values,
>> which I do not do (it can be added to my patch, but then I might do the whole ares_init as you do).
>> What is missing in your patch that needs some more work?
>>
>> Thanks for your feedback and insights,
>>
>> Nayanā
>>
>> Dňa 26. 8. 2019 o 3:22 Dima Tisnek napísal(a):
>>
>> Hi Nayana, it's awesome that you want to make this happen.
>>
>> The problem is actually more complex than this:
>> * [in some cases] c-ares is the only "good" resolved for libcurl, and
>> * [when I last checked] c-ares reads /etc/resolv.conf only once
>>
>> Thus, for a device that moves from network to network (e.g. wifi), has
>> a long-running process, needs domain name resolution timeouts (e.g.
>> wifi) and some other requirements (multithreaded IIRC, because libc
>> resolver uses a signal for timeout), this really is a problem.
>>
>> It may seem that this circumstances are peculiar, but, actually many
>> IoT devices fall into this category.
>>
>> Back in the day, I've tried to make a patch, but didn't have
>> time/stamina and couldn't put enough effort for it to be accepted.
>>
>> https://gist.github.com/dimaqq/397682b68cdc0992a5d314c53e8ecf86 has the code.
>>
>> The task is somewhat more complex than you stated, because resolv.conf
>> may contain several bits of configuration, and sometimes partial
>> update could break things (IIRC to resolve a LAN host, both `domain`
>> and `nameserver` are needed).
>>
>> Cheers,
>> d.
>>
>> On Thu, 15 Aug 2019 at 21:36, Nayanā Topolsky <nayana.topolsky_at_zoho.com> wrote:
>>
>> Hi,
>>
>> so I used just stat as the conf file is small, no need for 64bit version.
>> However I was not sure if I should ifdef the stat structure usages as well?
>>
>> So the pull request is there, the only systems that use /etc/resolv.conf are Linux and OSX, which both passed via CI tests.
>> I guess there are no win32 automated tests?
>>
>> Dňa 9. 8. 2019 o 9:02 Daniel Stenberg napísal(a):
>>
>> On Thu, 8 Aug 2019, Nayanā Topolsky wrote:
>>
>> I used stat64 function to check mtime and ctime and also size and ino values in very similar way as it is done in libc.
>>
>>
>> stat(), or variations of it, should be fairly portable over many systems. (In the curl project we do stat on basically *all* platforms with just this little setup magic: https://github.com/curl/curl/blob/master/lib/curl_setup.h#L361-L396)
>>
>> The particular file name(s) you check which that call could also be system specific but should be possible to be made to work on a fair amount of systems.
>>
>> I can send a patch (or pull request) with hope that somebody else will continue the work on it. Or maybe it would be mergable even in this way.
>>
>>
>> We will prefer a pull-request so that we get it somewhat verified before we consider merging and handling updates and reviews are also stream-lined that way.
>>
>> We can't guarantee that "somebody else" will magically continue working on it if you just drop it there though, I suppose it depends on how much work that remains...
>>
>> Thanks!
>>
Received on 2019-08-28