Included file does not re-up after updates

Docker Engine Compose
,
1

Hello,

I’ve got a compose file that use the include capabilities to include another Docker Compose file to build a stack.
In the included file (as well a the main one), the restart policy is set to unless-stopped.

When I do a package upgrade on my host (Ubuntu 24.04 : apt upgrade) and have Docker related packages upgraded, the container inside the included file is the only one that does not restart after the update.

For me, this is not normal, the included container should also restart after the upgrades but maybe I’m missing something…

To solve this, I’ve to manually up the stack (doing a docker compose up -d).

  • compose.yml :
# compose.yml BEGIN
include:
  - traefik.yml

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    restart: unless-stopped
    environment:
      GID: "${GID-1000}"
      COLLECTIONS: "crowdsecurity/linux crowdsecurity/traefik"
    security_opt:
      - no-new-privileges:true
    volumes:
      - /etc/crowdsec:/etc/crowdsec/
      - /var/lib/crowdsec/data:/var/lib/crowdsec/data/
      - /var/log/traefik/:/var/log/traefik/:ro
    networks:
      - traefik-net

networks:
  traefik-net:
    external: true
    name: traefik-net
# compose.yml END
  • traefik.yml :
# traefik.yml BEGIN
services:
  bouncer-traefik:
    image: docker.io/fbonalair/traefik-crowdsec-bouncer:latest
    container_name: bouncer-traefik
    restart: unless-stopped
    environment:
      CROWDSEC_BOUNCER_API_KEY: my-api-key
      CROWDSEC_AGENT_HOST: crowdsec:8080
    networks:
      - traefik-net
    depends_on:
      - crowdsec
# traefik.yml END

Do you have the same issue or do you know how to solve this ?
I had this issue since I started using this (about 6 month ago) and any Docker updates have fix it.

Client: Docker Engine - Community
Version: 29.1.2
API version: 1.52
Go version: go1.25.5
Git commit: 890dcca
Built: Tue Dec 2 21:55:19 2025
OS/Arch: linux/amd64
Context: default

Server: Docker Engine - Community
Engine:
Version: 29.1.2
API version: 1.52 (minimum version 1.44)
Go version: go1.25.5
Git commit: de45c2a
Built: Tue Dec 2 21:55:19 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.0
GitCommit: 1c4457e00facac03ce1d75f7b6777a7a851e5c41
runc:
Version: 1.3.4
GitCommit: v1.3.4-0-gd6d73eb8
docker-init:
Version: 0.19.0
GitCommit: de40ad0

Docker Compose version v5.0.0

2

What do you see when you run

docker compose config

?
It should show the final interpreted yaml. And are you sure the problem is that the traefik service is included? Have you tried (just for testing) adding that service to the main yaml?

3

With docker compose config, I see the whole thing :

name: crowdsec
services:
  bouncer-traefik:
    container_name: bouncer-traefik
    depends_on:
      crowdsec:
        condition: service_started
        required: true
    environment:
      CROWDSEC_AGENT_HOST: crowdsec:8080
      CROWDSEC_BOUNCER_API_KEY: *********************
    image: docker.io/fbonalair/traefik-crowdsec-bouncer:latest
    networks:
      traefik-net: null
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
  crowdsec:
    container_name: crowdsec
    environment:
      COLLECTIONS: crowdsecurity/linux crowdsecurity/traefik
      GID: "1000"
    image: crowdsecurity/crowdsec:latest
    networks:
      traefik-net: null
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    volumes:
      - type: bind
        source: /etc/crowdsec
        target: /etc/crowdsec
        bind: {}
      - type: bind
        source: /var/lib/crowdsec/data
        target: /var/lib/crowdsec/data
        bind: {}
      - type: bind
        source: /var/log/traefik/
        target: /var/log/traefik
        read_only: true
        bind: {}
networks:
  traefik-net:
    name: traefik-net
    external: true

On my fist deployment, it was a single file and does not seems to have issue with it.
I can put them back into a single file but I’m kinda sure it will work but I’ll have to wait for another Docker upgrade to verify it.

Strangely, this issue occurs only on upgrades, doing a systemctl restart docker or a server reboot both works as expected. I’ve just retry those test before replying to you.

4

How many upgrades did you have when you had the same issue?

Does that mean you had that first deployment file after you already had this issue with another compose project with “include”?

If there is a bug in the upgrade process that doesn’t allow some containers to be restarted, it is possible that having a single file would make it work again. Although I don’t see how that would actually happen, unless docker compose config returns an output wich is not used when actualyl creating and starting containers. After Docker Compose did its job, it is just Docker running containers as instructed by Docker Compose.

On the other hand, Docker Compose v5 is still new, and I should read more about it.

That is strange indeed. And makes it hard to reproduce anything.

5

I don’t really know… As I always do a package update weekly (manually so not 100% accurate)
Based on my Git history, this has been on production since Aug 24 2025.
Based on the Docker Compose Github release history, I was somewhere on Docker Compose v2.39.

No, this was the first time I use the include feature.
To be precise, on the server, I’ve got 10 others projects running without using the include capabilities (2 of them use docker-compose.override.yml).
When building the one, I’ve just found out about the include feature then I built this project using small steps :

  1. Put everything in one file
  2. Make sure everything is working
  3. Down the project (docker compose down)
  4. Split the file with the include feature
  5. Make sure everything is working

I don’t think this is related to v5 because I got this issue for some month already.

I’ve posted here mainly to be sure that I use it correctly and see if it’s a common issue.
As it seems I’ve done nothing wrong here, I will pursue the debug by deploying included files based compose on testing servers and see if I see a pattern there.

6

The behavior is indeed strange, docker compose is just another client for the docker api

Whatever docker compose config renders, is what is used to change or delete configuration for the listed resources over the docker api.

Did you inspect the resulting container, to see whether the restart policy is indeed configured?

It is not impossible that there is an issue with marshalling/unmarshalling somewhere between reading the compose file, creating structs for the individual resources, and perform one or more api calls per resource.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.