I would also like to see the official support of c-ares for detection of
resolv configuration change.
However the main blocker was that the implementation of my patch was not
taking into account other OS types .. and more general solution was
needed. That is not just specific for Linux/Mac and its resolv.conf -
which is fair point.
I am just a user, so this is more like opinion, but as I see it (correct
me if I am wrong, or missing a point), it must be designed to take into
account also other systems - from the very beginning.
My solution is currently used at our company, and it suits our need -
which is Linux specific.
For instance I am not sure what exactly happens to the pending resolve
requests when the change is detected and reinit is done.. and stuff like
So it would be better to have real, verified solution - properly tested.
Last thing - the support for resolv.conf change is already working in
glibc.. and the inspiration was taken from that ..
You can easily find the patch from 2017-07-03 ..
In the patch I am checking ctime,mtime, size, inode ..
Dňa 11. 6. 2020 o 20:48 Nicolas Sterchele napísal(a):
> Hi all,
> This is would be my first contribution to the library and before starting to code, I would like to have your opinion on the following points:
> I am thinking on implementing a "reinit" function based on the following closed PR (https://github.com/c-ares/c-ares/pull/272).
> My main concern is to trigger a "reinit" when the content of the resolv.conf file has changed.
> 1. "ares_reinit" would be a public function, library consumers must have the possibility to trigger a reinit.
> 2. Is it possible to call the following functions "init_by_options", "init_by_env" or "init_by_resolv" without worrying to break
> something on a channel? Would like to reuse those functions...
> 3. Based on the resolvconf scenario, we should call "reinit" when the file's "mtime" has changed. In order to track a change, a new variable would be added to the "ares_channeldata" struct.
> 3.1 Each time "ares_gethostbyname" is triggered, we should check if the file has changed (by comparing what we have in "ares_channeldata" and the actual "mtime").
> 4. Having c-ares to trigger a reinit by itself should be optional, the consumer of the library must be aware of that.
> I look forward to have your feedback!
Received on 2020-06-12