[ZBX-12408] Document the differences in name resolution in regular operation and with libcurl Created: 2015 Oct 15 Updated: 2024 Apr 10 Resolved: 2017 Sep 18 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Problem report | Priority: | Trivial |
Reporter: | Volker Fröhlich | Assignee: | Unassigned |
Resolution: | Duplicate | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||
Team: | |||||||||
Sprint: | Sprint 13, Sprint 14, Sprint 15, Sprint 16, Sprint 17 | ||||||||
Story Points: | 3 |
Description |
While the daemons run res_init() on startup to initialize glibc's name resolution mechanisms, libcurl uses its own backend to resolve names. I'm not an expert with libcurl, but as I understand it, the resolving configuration is basically initialized on every call to curl_easy_init(). This results in the artefact that web checks pick up changes in /etc/resolv.conf and presumably nsswitch.conf, gai.conf and host.conf (I don't mean "hosts"), while the daemons otherwise don't. I first thought that Zabbix could maybe resolve the name and just hand it over to libcurl, which is possible. However, I realized that this is no solution, because a redirect may require another name resolution, so this effect won't go away. I don't know if there's another solution. I would therefore ask you to document this behaviour, so we can point people somewhere, when the question arises. |
Comments |
Comment by Volker Fröhlich [ 2015 Oct 15 ] |
Somewhat related to |
Comment by Andris Mednis [ 2017 Sep 19 ] |
I investigated it and decided to fix as |