[ZBXNEXT-1862] Daemons should follow changes in resolv.conf Created: 2013 Aug 17 Updated: 2017 Nov 29 Resolved: 2017 Oct 10 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G), Java gateway (J), Proxy (P), Server (S) |
Affects Version/s: | 2.1.1 |
Fix Version/s: | 3.0.12rc1, 3.2.9rc1, 3.4.3rc1, 4.0.0alpha1, 4.0 (plan) |
Type: | Change Request | Priority: | Major |
Reporter: | Volker Fröhlich | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 2 |
Labels: | dns, name, resolution | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||||||
Team: | Team C | ||||||||||||
Sprint: | Sprint 17, Sprint 18 | ||||||||||||
Story Points: | 5 |
Description |
The Zabbix daemons should keep track of changes in resolv.conf. Changes to this file otherwise demand a restart of the daemon to become effective. With a glibc default timeout of 5 seconds, name resolution might not work properly anymore – no matter if name resolution is set to round robin or not. nscd uses inotify to keep track and it calls res_init() upon changes, as far as I saw. nsswitch.conf should probably also be taken care of. |
Comments |
Comment by Marc [ 2013 Aug 17 ] |
This is actually the expected behavior (calling res_init() only once). |
Comment by Aleksandrs Saveljevs [ 2014 Sep 30 ] |
Note that currently the only place we call res_init() explicitly is in "net.dns[]" and "net.dns.record[]" items on the agent side on Unix, and res_init() is called every time these items are queried. |
Comment by Volker Fröhlich [ 2014 Sep 30 ] |
I suggested this behaviour because Zabbix heavily relies on name resolution and as a monitoring system its operation is slightly more critical than usual. It's also about the inconsistency of the web monitoring picking up the changes and all other items don't. Part of the motivation is to keep the monitoring running, even if you have to fail over to a different name server. It could also be implented like the on-demand debugging level is in 2.4. Related: ZBXNEXT-1002 |
Comment by Andris Mednis [ 2017 Sep 12 ] |
Helpful links on this problem: |
Comment by Andris Mednis [ 2017 Sep 12 ] |
Reproduced with CentOS 4.92 and CentOS 7 with Zabbix agent 3.0.11rc1. On the other hand, Debian testing does not suffer from this issue - /etc/resolv.conf changes are timely picked up. |
Comment by Andris Mednis [ 2017 Sep 18 ] |
Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1862-30 for 3.0. |
Comment by Viktors Tjarve [ 2017 Sep 25 ] |
Successfully tested. |
Comment by Andris Mednis [ 2017 Sep 25 ] |
Fixed in versions:
|
Comment by Andris Mednis [ 2017 Sep 28 ] |
For 3.4 fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1862-34 wiper Looks good. andris Thanks ! |
Comment by Andris Mednis [ 2017 Sep 28 ] |
Documented in "What's New": martins-v Reviewed, with minor grammar adjustments. CLOSED |
Comment by Volker Fröhlich [ 2017 Sep 28 ] |
I would argue that they are "UNIXoid" or "UNIX-like", but that's just a remark. |
Comment by Andris Mednis [ 2017 Sep 28 ] |
Thanks, will be changed to ""Unix-like". |
Comment by richlv [ 2017 Oct 04 ] |
would it make sense to document how exactly it is done, how soon users can expect the changes to be picked up etc ? |
Comment by Andris Mednis [ 2017 Oct 04 ] |
Server, proxy and agentd processes have the main loop - do something, sleep, repeat. |
Comment by Andris Mednis [ 2017 Oct 05 ] |
richlv, how about |
Comment by richlv [ 2017 Oct 06 ] |
andris, that's great detail, thank you. maybe the second sentence can be shortened to "The change is noticed as a new modification time of ''/etc/resolv.conf'' file once in a work cycle of the main daemon process but not more frequently than once per second." ? probably worth running by martins-v |
Comment by Andris Mednis [ 2017 Oct 06 ] |
"The change is noticed as a new modification time of ''/etc/resolv.conf'' file once in a work cycle of the process but not more frequently than once per second." ? (each long-running process discovers ''/etc/resolv.conf" change on its own - unrelated to main daemon process) |