NTP check broken: Servname not supported for ai_socktype (missing /etc/services from netbase)
See original GitHub issueJust upgraded from 5.23.0 to 5.24.0 using the official docker image to resolve issue #1346 and it broke the NTP check with the following error:
2018-05-17 11:30:31 UTC | INFO | dd.collector | config(config.py:1249) | initialized checks.d checks: ['kube_dns', 'network', 'kubernetes', 'ntp', 'docker_daemon', 'http_check', 'system_core', 'redisdb', 'disk', 'kube_proxy']
2018-05-17 11:30:31 UTC | INFO | dd.collector | config(config.py:1250) | initialization failed checks.d checks: []
2018-05-17 11:30:31 UTC | INFO | dd.collector | collector(agent.py:166) | Check reload was successful. Running 11 checks.
2018-05-17 11:30:35 UTC | ERROR | dd.collector | checks.ntp(__init__.py:829) | Check 'ntp' instance #0 failed
Traceback (most recent call last):
File "/opt/datadog-agent/agent/checks/__init__.py", line 812, in run
self.check(copy.deepcopy(instance))
File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/datadog_checks/ntp/ntp.py", line 33, in check
ntp_stats = ntplib.NTPClient().request(**req_args)
File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/ntplib.py", line 292, in request
addrinfo = socket.getaddrinfo(host, port)[0]
gaierror: [Errno -8] Servname not supported for ai_socktype
Output of the info page
[0;31mWarning: Known bug in Linux Kernel 3.18+ causes 'status' to fail.[0m
Calling 'info', instead...
====================
Collector (v 5.24.0)
====================
Status date[0m: 2018-05-17 11:24:41 (6s ago)[0m
Pid: 37
Platform: Linux-4.4.111+-x86_64-with-debian-9.4
Python Version: 2.7.14, 64bit
Logs: <stderr>, /var/log/datadog/collector.log
Clocks
======
NTP offset: Unknown ([Errno -8] Servname not supported for ai_socktype)
System UTC time: 2018-05-17 11:24:47.882946
Paths
=====
conf.d: /etc/dd-agent/conf.d
checks.d: Not found
Hostnames
=========
socket-hostname: dd-agent-bsljm
hostname: <snip>.internal
socket-fqdn: dd-agent-bsljm
Checks
======
kube_dns (1.3.0)
----------------
- instance #0 [[32mOK[0m]
- Collected 44 metrics, 0 events & 0 service checks
network (1.5.0)
---------------
- instance #0 [[32mOK[0m]
- Collected 122 metrics, 0 events & 0 service checks
kubernetes (1.5.0)
------------------
- instance #0 [[32mOK[0m]
- Collected 402 metrics, 0 events & 3 service checks
ntp (1.2.0)
-----------
- Collected 0 metrics, 0 events & 0 service checks
docker_daemon (1.10.0)
----------------------
- instance #0 [[32mOK[0m]
- Collected 527 metrics, 0 events & 1 service check
http_check (2.0.1)
------------------
- instance #0 [[32mOK[0m]
- instance #1 [[32mOK[0m]
- Collected 8 metrics, 0 events & 4 service checks
system_core (1.0.0)
-------------------
- instance #0 [[32mOK[0m]
- Collected 41 metrics, 0 events & 0 service checks
redisdb (1.5.0)
---------------
- instance #0 [[32mOK[0m]
- Collected 44 metrics, 0 events & 1 service check
- Dependencies:
- redis: 2.10.5
disk (1.2.0)
------------
- instance #0 [[32mOK[0m]
- Collected 58 metrics, 0 events & 0 service checks
kube_proxy (Unknown Wheel)
--------------------------
- Collected 0 metrics, 0 events & 0 service checks
Emitters
========
- http_emitter [[32mOK[0m]
====================
Dogstatsd (v 5.24.0)
====================
Status date[0m: 2018-05-17 11:24:48 (0s ago)[0m
Pid: 34
Platform: Linux-4.4.111+-x86_64-with-debian-9.4
Python Version: 2.7.14, 64bit
Logs: <stderr>, /var/log/datadog/dogstatsd.log
Flush count: 119
Packet Count: 7177
Packets per second: 5.5
Metric count: 109
Event count: 0
Service check count: 0
====================
Forwarder (v 5.24.0)
====================
Status date[0m: 2018-05-17 11:24:48 (0s ago)[0m
Pid: 33
Platform: Linux-4.4.111+-x86_64-with-debian-9.4
Python Version: 2.7.14, 64bit
Logs: <stderr>, /var/log/datadog/forwarder.log
Queue Size: 1559 bytes
Queue Length: 1
Flush Count: 387
Transactions received: 302
Transactions flushed: 301
Transactions rejected: 0
API Key Status: API Key is valid
======================
Trace Agent (v 5.24.0)
======================
Pid: 32
Uptime: 1193 seconds
Mem alloc: 4502136 bytes
Hostname: <snip>.internal
Receiver: 0.0.0.0:8126
API Endpoint: https://trace.agent.datadoghq.com
--- Receiver stats (1 min) ---
From go 1.9.2 (gc-amd64-linux), client v0.5.0
Traces received: 19 (9127 bytes)
Spans received: 38
Services received: 0 (0 bytes)
--- Writer stats (1 min) ---
Traces: 6 payloads, 18 traces, 4801 bytes
Stats: 4 payloads, 5 stats buckets, 4440 bytes
Services: 0 payloads, 0 services, 0 bytes
Additional environment details (Operating System, Cloud provider, etc):
- Official docker image 12.6.5240
- Google Kubernetes Engine 1.8.10.gke0 with Container Optimized OS
Steps to reproduce the issue:
- install datadog agent on kubernetes using official docker image 12.6.5240
- check the logs
Describe the results you received:
The Servname not supported for ai_socktype
error happens when the NTP check is executed.
Describe the results you expected:
No error.
Additional information you deem important (e.g. issue happens only occasionally):
Did not happen with 5.23.0
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
ntpd: Synchronizing with time server: Error : Servname not ...
Description of problem: When I start the ntp service up I get the following ... Error : Servname not supported for ai_socktype [FAILED]...
Read more >Error: Servname not supported for ai_socktype - Marius Ducea
The conclusion of this post is to check if you have the application ports defined in /etc/services if you encounter such an error…...
Read more >Servname not supported for ai_socktype - Stack Overflow
I had this problem with a Tornado/Python app. Apparently, this can be caused by the port being interpreted as a string instead of...
Read more >network applications throwing "Servname not supported for ...
This can occur when, due to misconfiguration, an unprivileged user does not have read access to /etc/services . Check with:
Read more >ntpdate: Error : Servname not supported for ai_socktype
Acknowledgement sent to Philipp Frauenfelder <pfrauenf@debian.org> : New Bug report received and forwarded. Copy sent to Debian NTP Team <debian ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The container needs a file to define the ntp port at /etc/services
We map this in using kubernetes volume, but should be fixed upstream.
Sounds good to me.