GitLab-CI: Cannot link to a non running container

Question

I've tried to get my setup work with gitlab-ci. I have a simple gitlab-ci.yml file

build_ubuntu:
  image: ubuntu:14.04
  services:
    - rikorose/gcc-cmake:gcc-5
  stage: build
  script:
    - apt-get update
    - apt-get install -y python3 build-essential curl
    - cmake --version
  tags:
    - linux

I want to get a ubuntu 14.04 LTS with gcc and cmake (apt-get version is to old) installed. If i use it locally (via docker --link command) everything works, but when the gitlab-ci-runner will process it i get the following waring (which is in my case an error)

Running with gitlab-ci-multi-runner 9.2.0 (adfc387)
on xubuntuci1 (19c6d3ce)
Using Docker executor with image ubuntu:14.04 ...
Starting service rikorose/gcc-cmake:gcc-5 ...
Pulling docker image rikorose/gcc-cmake:gcc-5 ...
Using docker image rikorose/gcc-cmake:gcc-5 
ID=sha256:ef2ac00b36e638897a2046c954e89ea953cfd5c257bf60103e32880e88299608 
for rikorose/gcc-cmake service...
Waiting for services to be up and running...

*** WARNING: Service runner-19c6d3ce-project-54-concurrent-0-rikorose__gcc-
cmake probably didn't start properly.

Error response from daemon: Cannot link to a non running container: /runner-
19c6d3ce-project-54-concurrent-0-rikorose__gcc-cmake AS /runner-19c6d3ce-
project-54-concurrent-0-rikorose__gcc-cmake-wait-for-service/runner-
19c6d3ce-project-54-concurrent-0-rikorose__gcc-cmake

Does anybody know how i can fix this?

Thanks in advance Tonka

docker run -itd rikorose/gcc-cmake:gcc-5 --link=myrunningubuntucontainer — Michael Aigner, May 30 '17 at 15:05
Do you use shared runners or have you set up your own runner? — Jakub Kania, May 31 '17 at 08:05

wendellmva · Accepted Answer · 2021-01-11T00:09:50.727

26

You must start the gitlab-runner container with

--privileged true

but that is not enough. Any runner containers that are spun up by gitlab after registering need to be privileged too. So you need to mount the gitlab-runner

docker exec -it runner /bin/bash
nano /etc/gitlab-runner/config.toml

and change privileged flag from false into true:

privileged = true

That will solve the problem!

note: you can also mount the config.toml as a volume on the container then you won't have to log into the container to change privileged to true because you can preconfigure the container before running it.

edited Jan 11 '21 at 00:09

answered Sep 24 '17 at 22:10

wendellmva

1,896
1
26
33

Exactly this fixed it for me, many thanks! As far as I can see it's not mentioned in the official instructions.... – JosephH Jan 22 '18 at 11:02
7

I already start container in privileged mode. This does not helped me. – Dimitri Kopriwa Oct 12 '20 at 12:32
Starting the container in privilege mode is not enough. Did you log in to the container and changed the privileged flag in the config.toml? – wendellmva Oct 13 '20 at 21:32
1

@wendellmva I don't get it. Why I need to loging to container, this is not normal. – holms Jan 10 '21 at 09:05
1

@holms, it is if you think about how gitlab runners work. The gitlab ci-cd is a subsystem that uses the gitlab-runner container you defined to start copies of itself to host multiple concurrent build stages and processes. They all need to be privileged. So the first flag is for the first container, the second is for the all the containers that are spun up by gitlab. – wendellmva Jan 11 '21 at 00:04
Making runners privileged is an awful solution to any problem that should not require these privileges. This introduces a huge security hole in your setup. What may be happening is that your service runs and then fails. I encountered this problem because my job caused the service to crash, so it was unable to attach to it afterwards, as it was no longer running. – Thermostat Aug 23 '21 at 12:39
@Thermostat it maybe a terrible solution but it's the one recommended by gitlab, somewhere, and moreover it works. If you want to make your runners more secure, point them to your ssh keys and turn on ssh, there's nothing more secure then that. – wendellmva Aug 25 '21 at 20:11

score 1 · Answer 2 · answered Jan 11 '23 at 14:31

1

In my case, I had to add

variables:
  DOCKER_TLS_CERTDIR: ""

answered Jan 11 '23 at 14:31

sareno

576
8
10

On a side-note: This usually is done to force dind to start in non-TLS mode, other users use `command: ["--tls=false"]` on the service to achieve this. For me, the tls=false didnt worked, but specifying the variable did. Its also possible to use dind with TLS, but it requires sharing a volume with the certs between the task-container and the service. I believe TLS-as-default (=port 2736, not 2735) came after dind-v19. – leberknecht Jun 23 '23 at 08:54

score 1 · Answer 3 · answered Apr 06 '23 at 16:44

Though my CI configuration is different and it is serving a different purpose, I came across a similar issue basically resulting in the same error message referring to the attempt to link some non-running container.

Related runner has been working privileged for years. However, the service used in the particular project's .gitlab-ci.yml file was pretty outdated. It was including this definition:

  services:
    - docker:18.09-dind

Docker on host was already at v23.x, so changing that definition accordingly fixed it for me:

  services:
    - docker:23-dind

GitLab-CI: Cannot link to a non running container

3 Answers3

Linked