Containers using network_mode: "service:<container>" lose shared network namespace after target container restart

[mattangus]

Summary

I'm seeing an issue where a container configured with:

network_mode: "service:gluetun"

eventually loses its shared network namespace after the target container (gluetun) has restarted.

Docker metadata continues to report the correct NetworkMode, but the running container is no longer in the same Linux network namespace as the target container.

Restarting only the dependent container immediately restores correct operation.

---

Environment

Docker Engine: 29.1.3
containerd:    2.2.1
runc:          1.3.4
Docker Compose: v5.1.2

Kernel:
Linux 5.15.0-179-generic
Ubuntu 22.04

---

Configuration

Simplified compose configuration:

services:
  gluetun:
    image: qmcgaw/gluetun:v3.39.1
    restart: unless-stopped

  sonarr:
    image: ghcr.io/linuxserver/sonarr
    network_mode: "service:gluetun"
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

---

Expected behaviour

The dependent container should continue sharing the target container's network namespace for its lifetime.

Running:

ip addr
ip route

inside both containers should produce identical networking.

---

Actual behaviour

After the system has been running for some time, the dependent container loses network connectivity.

Symptoms:

• HTTP requests through Traefik begin returning 502 Bad Gateway
• ping 8.8.8.8 returns Network unreachable
• ip addr inside the dependent container only shows the loopback interface
• ip route is empty

Restarting only the dependent container fixes the issue immediately.

docker compose restart sonarr

No restart of the target (gluetun) container is required.

---

Diagnostics

Target container

$ docker compose exec gluetun ip addr

lo
eth0
tun0

$ docker compose exec gluetun ip route

0.0.0.0/1 via 10.16.0.1 dev tun0
default via 172.19.0.1 dev eth0
...

Dependent container

$ docker compose exec sonarr ip addr

lo

$ docker compose exec sonarr ip route

# empty

---

Network namespaces

Target container:

$ ls -l /proc/<gluetun-pid>/ns/net

net:[4026533515]

Dependent container:

$ ls -l /proc/<sonarr-pid>/ns/net

net:[4026533104]

The namespace inodes differ. After restarting sonarr the inodes are the same /proc/3679814/ns/net -> 'net:[4026533515]'

---

Docker metadata

Docker still reports the expected configuration:

$ docker inspect sonarr --format '{{.HostConfig.NetworkMode}}'

container:58b4b78bb970262122e6a0b4342e71b02def261070e1713b31be55b52d319154

The referenced container ID matches the currently running target container:

$ docker inspect gluetun --format '{{.Id}}'

58b4b78bb970262122e6a0b4342e71b02def261070e1713b31be55b52d319154

The container has no independently attached networks, as expected:

$ docker inspect sonarr --format '{{json .NetworkSettings.Networks}}'

{}

---

Additional observations

The target container has restarted several times:

$ docker inspect gluetun --format '{{.RestartCount}}'

5

The dependent container has never restarted:

$ docker inspect sonarr --format '{{.RestartCount}}'

0

After the issue occurs:

• Docker metadata still reports the correct NetworkMode.
• The kernel reports the two containers are in different network namespaces.
• Restarting only the dependent container immediately restores networking.

---

Could this be a generic docker issue or specific to gluetun's configuration? Any help to point me in the right direction would be appreciated. I'm tired of restarting all my containers every few days!

[cookesan]

This points much more to Docker/Compose namespace lifecycle than to Gluetun-specific routing.

Gluetun's documented compose pattern is exactly network_mode: "service:gluetun" for another service in the same compose file. That makes the dependent container join Gluetun's network namespace when the dependent container is started. Your diagnostics line up with that: restarting only sonarr fixes it because sonarr rejoins the current Gluetun namespace.

The weak spot is restart propagation. depends_on with condition: service_healthy controls startup ordering/readiness; it does not mean a dependent container is dynamically reattached whenever the dependency's network namespace changes. Docker's Compose docs also distinguish depends_on: ... restart: true as applying when the dependency is restarted by an explicit Compose operation, not as a general cascade for the runtime restart: unless-stopped policy.

So the practical mitigation is to restart the dependents after Gluetun restarts and is healthy:

docker compose restart sonarr

or the equivalent for all services using network_mode: "service:gluetun".

If your Gluetun restarts are initiated by Compose, add long-form depends_on with restart: true to the dependent services and test that path. If Gluetun is restarting because the Docker daemon/runtime restart policy is bringing it back after an exit, use a small watchdog/systemd unit/health hook that waits for Gluetun to become healthy and then restarts the dependent services. I would not expect Gluetun itself to be able to repair another already-running container's namespace from inside the VPN container.