[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:
Duplicate
is duplicated by ZBX-11253 agent uses DNS server which it rememb... Closed
is duplicated by ZBX-12408 Document the differences in name reso... Closed
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).
Why do you think this needs to be changed for Zabbix daemons?

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:
https://sourceware.org/bugzilla/show_bug.cgi?id=984
https://bugzilla.mozilla.org/show_bug.cgi?id=214538

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:

  • pre-3.0.12rc1 r72894
  • pre-3.2.9rc1 r72990
  • pre-3.4.3rc1 r73035
  • pre-4.0.0alpha1 (trunk) r 73036
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":
https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew3012#daemon_improvements
https://www.zabbix.com/documentation/3.2/manual/introduction/whatsnew329#daemon_improvements
https://www.zabbix.com/documentation/3.4/manual/introduction/whatsnew343#daemon_improvements

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.
This change modifies the main loop: do something, sleep, check /etc/resolv.conf, repeat.
For some quickly spinning processes there is a limit - check /etc/resolv.conf less often than once a second.

Comment by Andris Mednis [ 2017 Oct 05 ]

richlv, how about
"On UNIX systems the Zabbix server, proxy and agent now follow changes in ''/etc/resolv.conf'' file without restart.
The change is noticed as a new modification time of ''/etc/resolv.conf'' file, it is not picked up instantly but reasonably soon - once in a work cycle (e.g. in the next check)." ?

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)

Generated at Fri Mar 29 09:03:40 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.