question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

NTP check broken: Servname not supported for ai_socktype (missing /etc/services from netbase)

See original GitHub issue

Just 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

Warning: Known bug in Linux Kernel 3.18+ causes 'status' to fail.
Calling 'info', instead...
====================
Collector (v 5.24.0)
====================

  Status date: 2018-05-17 11:24:41 (6s ago)
  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 [OK]
      - Collected 44 metrics, 0 events & 0 service checks
  
    network (1.5.0)
    ---------------
      - instance #0 [OK]
      - Collected 122 metrics, 0 events & 0 service checks
  
    kubernetes (1.5.0)
    ------------------
      - instance #0 [OK]
      - 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 [OK]
      - Collected 527 metrics, 0 events & 1 service check
  
    http_check (2.0.1)
    ------------------
      - instance #0 [OK]
      - instance #1 [OK]
      - Collected 8 metrics, 0 events & 4 service checks
  
    system_core (1.0.0)
    -------------------
      - instance #0 [OK]
      - Collected 41 metrics, 0 events & 0 service checks
  
    redisdb (1.5.0)
    ---------------
      - instance #0 [OK]
      - Collected 44 metrics, 0 events & 1 service check
      - Dependencies:
          - redis: 2.10.5
  
    disk (1.2.0)
    ------------
      - instance #0 [OK]
      - Collected 58 metrics, 0 events & 0 service checks
  
    kube_proxy (Unknown Wheel)
    --------------------------
      - Collected 0 metrics, 0 events & 0 service checks
  
  
  Emitters
  ========
  
    - http_emitter [OK]

====================
Dogstatsd (v 5.24.0)
====================

  Status date: 2018-05-17 11:24:48 (0s ago)
  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: 2018-05-17 11:24:48 (0s ago)
  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:

  1. install datadog agent on kubernetes using official docker image 12.6.5240
  2. 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:closed
  • Created 5 years ago
  • Comments:6 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
nhoughtocommented, May 23, 2018

The container needs a file to define the ntp port at /etc/services

 ntp   123/tcp
 ntp   123/udp

We map this in using kubernetes volume, but should be fixed upstream.

0reactions
pdecatcommented, May 25, 2018

Sounds good to me.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found