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