Gitlab-runner: npm ci getaddrinfo EAI_AGAIN registry.npmjs.org

Danny-P · January 9, 2021, 9:43pm

I try to use a gitlab CI pipeline with my angular project in Docker.
But gitlab-runner fais with an error messagen when performing npm ci:

$ [ -d node_modules ] || npm ci
npm ERR! code EAI_AGAIN
npm ERR! errno EAI_AGAIN
npm ERR! request to https://registry.npmjs.org/@types/node/-/node-12.19.9.tgz failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org registry.npmjs.org:443

I am using a locally installed gitlab-ce instance.
Gitlab-ce Version: 13.7.3-ce.0
Gitlab-Runner: 13.7.0

That’s my Dockerfile:

FROM nginx:1.19.6-alpine
COPY nginx.conf /etc/nginx/nginx.conf
COPY /dist/frontend /usr/share/nginx/html

And that’s my gitlab-ci.yml

stages:
- init

variables:
  DIST_DIR: dist/mailadmin-frontend
  CLI_VERSION: 7.3.9

cache:
  key: ${CI_COMMIT_SHA}
  paths: ['mailadmin-frontend/node_modules']

before_script:
- cd /builds/dp/mailadmin-frontend/
- "[ -d node_modules ] || npm ci"
init:
  stage: init
  image: trion/ng-cli:${CLI_VERSION}
  script: ['']
  cache:
    policy: push
    key: ${CI_COMMIT_SHA}
    paths: ['mailadmin-frontend/node_modules']
  tags: 
  - docker

hchouraria · February 8, 2021, 3:07pm

The EAI_AGAIN occurs when a getaddrinfo call (a DNS request to resolve a hostname to its IP) times out or is rejected by the DNS server it contacted.

Given the default NPM addresses in use, this appears to be an internet infrastructure driven issue. If this is frequent, you’ll need to figure out which DNS server the request hits by using a command such as dig registry.npmjs.org and try to run a local DNS cache service (such as dnsmasq) if the upstream DNS endpoint (such as the one provided by the ISP) is not reliable under load.

philippe-granet · June 27, 2022, 9:15pm

If your problem is random, there is also known problems with DNS in Docker alpine images:

github.com

gliderlabs/docker-alpine/blob/master/docs/caveats.md#dns

# Caveats

The musl libc implementation may work a little different than you are used to. The [musl libc differences from glibc document](http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Name_Resolver_.2F_DNS) does a really good job of outlining everything. Please take a glance at it. Here we'll talk about some of the more common things you might encounter.

## DNS

One common issue you may find is with DNS. musl libc does not use `domain` or `search` directives in the `/etc/resolv.conf` file. For example, if you started your Docker daemon with `--dns-search=service.consul`, and then tried to resolve `consul` from within an Alpine Linux container, it would fail as the name `consul.service.consul` would not be tried. You will need to work around this by using fully qualified names.

Another difference is parallel querying of name servers. This can be problematic if your first name server has a different DNS view (such as service discovery through DNS). For example, if you started your Docker daemon with `--dns=172.17.42.1 --dns=10.0.2.15` where `172.17.42.1` is a local DNS server to resolve name for service discovery and `10.0.2.15` is for external DNS resolving, you wouldn't be able to guarantee that `172.17.42.1` will always be queried first. There will be sporadic failures.

In both of these cases, it can help to run a local caching DNS server such as dnsmasq, that can be used for both caching and search path routing. Running dnsmasq with `--server /consul/10.0.0.1` would forward queries for the `.consul` to 10.0.0.1.

## Incompatible Binaries

While there are binaries that will run on musl libc without needing to be recompiled, you will likely encounter binaries and applications that rely on specific glibc functionality that will fail to start up. An example of this would be Oracle Java which relies on specific symbols only found in glibc. You can often use `ldd` to determine the exact symbol:

```console
# ldd bin/java
    /lib64/ld-linux-x86-64.so.2 (0x7f542ebb5000)
    libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f542ebb5000)

This file has been truncated. show original

github.com/gliderlabs/docker-alpine

DNS Issue

opened 02:50PM - 19 Feb 17 UTC

MosheMoradSimgo

question

Hi, We are running alpine (3.4) in a docker container over a Kubernetes clust…er (GCP). We have been seeing some anomalies where our thread is stuck for 2.5 sec. After some research using strace we saw that DNS resolving gets timed-out once in a while. Here are some examples: ``` 23:18:27 recvfrom(5, "\f\361\201\203\0\1\0\0\0\1\0\0\2db\6devone\5*****\3net\3svc\7cluster\5local\0\0\1\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\243\213\360\0\0p\200\0\0\34 \0\t:\200\0\0\0<", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.3.240.10")}, [16]) = 148 <0.000045> 23:18:27 recvfrom(5, 0x7ffdd0e1fb90, 512, 0, 0x7ffdd0e1f640, 0x7ffdd0e1f61c) = -1 EAGAIN (Resource temporarily unavailable) <0.000014> 23:18:27 clock_gettime(CLOCK_REALTIME, {1487114307, 714908396}) = 0 <0.000015> 23:18:27 poll([{fd=5, events=POLLIN}], 1, 2499) = 0 (Timeout) <2.502024> ``` ``` 09:04:27 recvfrom(5<UDP:[0.0.0.0:36148]>, "\354\211\201\203\0\1\0\0\0\1\0\0\2db\6devone\5*****\3net\3svc\7cluster\5local\0\0\1\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\244\30\220\0\0p\200\0\0\34 \0\t:\200\0\0\0<", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.3.240.10")}, [16]) = 148 <0.000041> 09:04:27 recvfrom(5<UDP:[0.0.0.0:36148]>, 0x7ffec3d9b0b0, 512, 0, 0x7ffec3d9ab60, 0x7ffec3d9ab3c) = -1 EAGAIN (Resource temporarily unavailable) <0.000011> 09:04:27 clock_gettime(CLOCK_REALTIME, {1487149467, 555317749}) = 0 <0.000008> 09:04:27 poll([{fd=5<UDP:[0.0.0.0:36148]>, events=POLLIN}], 1, 2498) = 0 (Timeout) <2.499671> ``` ``` 09:18:47 recvfrom(5<UDP:[0.0.0.0:47282]>, " B\201\200\0\1\0\1\0\0\0\0\2db\6devone\5*****\3net\0\0\1\0\1\300\f\0\1\0\1\0\0\0\200\0\4h\307\16N", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.3.240.10")}, [16]) = 53 <0.000011> 09:18:47 recvfrom(5<UDP:[0.0.0.0:47282]>, 0x7ffdd0e1fb90, 512, 0, 0x7ffdd0e1f640, 0x7ffdd0e1f61c) = -1 EAGAIN (Resource temporarily unavailable) <0.000008> 09:18:47 clock_gettime(CLOCK_REALTIME, {1487150327, 679292144}) = 0 <0.000005> 09:18:47 poll([{fd=5<UDP:[0.0.0.0:47282]>, events=POLLIN}], 1, 2497) = 0 (Timeout) <2.498797> ``` And a good example: ``` 08:22:25 recvfrom(5<UDP:[0.0.0.0:59162]>, "\20j\201\203\0\1\0\0\0\1\0\0\2db\6devone\5*****\3net\3svc\7cluster\5local\0\0\34\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\244\n\200\0\0p\200\0\0\34 \0\t:\200\0\0\0<", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.3.240.10")}, [16]) = 148 <0.000014> 08:22:25 recvfrom(5<UDP:[0.0.0.0:59162]>, 0x7ffec3d9aeb0, 512, 0, 0x7ffec3d9ab60, 0x7ffec3d9ab3c) = -1 EAGAIN (Resource temporarily unavailable) <0.000011> 08:22:25 clock_gettime(CLOCK_REALTIME, {1487146945, 638264715}) = 0 <0.000010> 08:22:25 poll([{fd=5<UDP:[0.0.0.0:59162]>, events=POLLIN}], 1, 2498) = 1 ([{fd=5, revents=POLLIN}]) <0.000010> ``` In the past we already had some issues with DNS resolving in older an version(3.3), which have been resolved since we moved to 3.4 (or so we thought). Is this a known issue? Does anybody have a solution / workaround / suggestion what to do? Thanks a lot.

Topic		Replies	Views
Npm publish fail on gitlab registry from gitlab CI GitLab CI/CD ci , runner , registry	7	12852	November 24, 2022
Gitlab runner fails with exit code 1 GitLab CI/CD ci , runner , docker	0	1339	March 8, 2023
Npm ci = 403 403 Forbidden GitLab CI/CD	0	2641	November 27, 2021
GitLab CI/CD - npm not found GitLab CI/CD runner , cicd	15	35254	August 19, 2024
Npm ERR! code CERT_HAS_EXPIRED GitLab CI/CD pipelines	3	9400	April 15, 2021

Gitlab-runner: npm ci getaddrinfo EAI_AGAIN registry.npmjs.org

Related topics