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.topol...@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.topol...@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!
