Also, when you say ‘The same container’ do you mean the same source:

yes Same Source.

The same source for a container isn’t guaranteed (and in fact is somewhat unlikely) to produce the same image. There are two pretty reasonable possibilities here

• The base image, python:3.10.13-slim-bullseye, was broken and a fix was pushed. This is not uncommon, but I’d also expect some other people to report issues. A new revision can (and likely would be) pushed under the same tag if there was a glitch fixed.
• There’s some corruption of your particular image on your build host.

In this case I’d go with the latter explanation.

Short solution (assuming this is the issue): Remove the source container images and re-pull them before re-building

# Remove image
$ docker image rm python:3.10.13-slim-bullseye
# Pull image again
$ docker pull python:3.10.13-slim-bullseye
3.10.13-slim-bullseye: Pulling from library/python
0bc8ff246cb8: Pull complete
ea6c70a3b047: Pull complete
94293398fb1c: Pull complete
2b0c0766ac49: Pull complete
5e93a6aa11f2: Pull complete
Digest: sha256:829bfd6812e20121a26a14bc419b375ee405d1c24dc252f9b740637c4701b122
Status: Downloaded newer image for python:3.10.13-slim-bullseye
docker.io/library/python:3.10.13-slim-bullseye

BEWARE! The output must include Pull complete for each layer! Otherwise, the Docker daemon is re-using cached layers, which is what we want to avoid. If you’re having trouble removing all the layers, try ‘pruning’ the Docker images (see https://stackoverflow.com/a/44791684/1120802) or, in the most extreme case, remove all the docker engine resources and start again (see Docker image corruption? Remove layers?). Be careful, both are destructive actions!

Next, re-build and set the --no-cache option

$ docker build -t your-image-name-here --no-cache .

If this doesn’t resolve the issue, see the "Not in image issue?" section below.

Full Explanation:

This is an explanation and demonstration of how this happens, NOT steps to fix this class of issue!

To troubleshoot an issue with a bad image, we can use docker image ls to find the ID of our target image:

$ sudo docker image ls
REPOSITORY    TAG                     IMAGE ID       CREATED          SIZE
redis         latest                  7f27d60cb8e0   12 days ago      138MB
python        3.10.13-bullseye        1a28f256af27   4 weeks ago      911MB
python        3.10.13-slim-bullseye   ee6be26d226b   4 weeks ago      126MB
ubuntu        latest                  e4c58958181a   5 weeks ago      77.8MB

The image ID is the more precise identifier for the set of bytes composing a given Docker image. In my case, 3.10.13-slim-bullseye has the (shortened) ID of ee6be26d226b. If this were to differ between machines, we’d know that the image is different. For the sake of example, we can see how the ubuntu:latest image is different (on a different machine) before and after pulls:

$ docker image ls
REPOSITORY    TAG           IMAGE ID       CREATED        SIZE
ubuntu        latest        6a47e077731f   2 months ago   69.2MB
$ docker pull ubuntu:latest
latest: Pulling from library/ubuntu
bfbe77e41a78: Pull complete
Digest: sha256:2b7412e6465c3c7fc5bb21d3e6f1917c167358449fecac8176c6e496e5c1f05f
Status: Downloaded newer image for ubuntu:latest
$ docker image ls
REPOSITORY    TAG           IMAGE ID       CREATED        SIZE
ubuntu        latest        e343402cadef   5 weeks ago    69.2MB

A given docker image is composed of ‘layers’ (you’ve probably seen them referenced with pushing to or pulling from a registry). After pulling an image, these layers reside on the local filesystem. Unfortunately, the contents of these layers can be corrupted when the image is first written to disk, when pulling into the final image, or any time in-between. As an example of how this could happen, let’s intentionally introduce corruption and examine how this appears. We’ll use the base image referenced in this post, python:3.10.13-slim-bullseye as an example.

First, find the UpperDir of the image we’re using. This is a one-liner that packs a bit together, but outputs the location on our filesystem where some of our base container contents are stored:

$ docker image inspect python:3.10.13-slim-bullseye --format="{{json .GraphDriver.Data.UpperDir}}" | jq -r | sed 's/diff//'
/var/lib/docker/overlay2/a9c2824fa4a07f72827b358a7a92480975e9243b30158e4dabf8c5808ed65928/

Neat, now let’s corrupt our image:

$ touch /var/lib/docker/overlay2/a9c2824fa4a07f72827b358a7a92480975e9243b30158e4dabf8c5808ed65928/hello-from-corruption-town

Finally, build a container using the referenced image. In this example I’m using the Dockerfile included below. Note the --no-cache!

$ docker build -t so-hack --no-cache .
[+] Building 5.6s (9/9) FINISHED                                                                                                                                                                                                                                     docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                                                                                                           0.0s
 => => transferring dockerfile: 746B                                                                                                                                                                                                                                           0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                                                              0.0s
 => => transferring context: 2B                                                                                                                                                                                                                                                0.0s
 => [internal] load metadata for docker.io/library/python:3.10.13-slim-bullseye                                                                                                                                                                                                0.0s
 => CACHED [1/5] FROM docker.io/library/python:3.10.13-slim-bullseye                                                                                                                                                                                                           0.0s
 => [2/5] RUN <<EOF cat >> /tmp/requirements.txt                                                                                                                                                                                                                               0.4s
 => [3/5] RUN pip install --no-cache-dir -r /tmp/requirements.txt                                                                                                                                                                                                              4.6s
 => [4/5] WORKDIR /app                                                                                                                                                                                                                                                         0.0s
 => [5/5] RUN <<EOF cat >> app.py                                                                                                                                                                                                                                              0.3s
 => exporting to image                                                                                                                                                                                                                                                         0.2s
 => => exporting layers                                                                                                                                                                                                                                                        0.2s
 => => writing image sha256:8bcd9ca6e43b5d94644e3c284b99c83a156f6fdfe0fb3d81a3a4ce3bebb9c763                                                                                                                                                                                   0.0s
 => => naming to docker.io/library/so-hack                                                                                                                                                                                                                                     0.0s

Finally, run the image and list the contents of the root filesystem.

$ docker run -it --rm so-hack /bin/bash -c 'ls /'
app  bin  boot  dev  etc  hello-from-corruption-town  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Our flag, hello-from-corruption-town, is present our image! Let’s see what happens if we try re-pulling the image:

$ docker pull python:3.10.13-slim-bullseye
3.10.13-slim-bullseye: Pulling from library/python
Digest: sha256:829bfd6812e20121a26a14bc419b375ee405d1c24dc252f9b740637c4701b122
Status: Image is up to date for python:3.10.13-slim-bullseye
docker.io/library/python:3.10.13-slim-bullseye
$ ls /var/lib/docker/overlay2/a9c2824fa4a07f72827b358a7a92480975e9243b30158e4dabf8c5808ed65928/
committed  diff  hello-from-corruption-town  link  lower  work

We can see that re-pulling a corrupt image will not fix the image. In this example we have added a flag (hello-from-corruption-town) but this could also be corruption of some other form, whether that’s a bad binary, truncated file, or missing directory. The best solution is to remove all related images and download the image layers again.

Wait, not in image issue?

Try building a minimal reproduction of the issue, such as starting with a minimal Dockerfile such as the following:

FROM python:3.10.13-slim-bullseye

RUN <<EOF cat >> /tmp/requirements.txt
celery[redis]==5.3.4
EOF

RUN pip install --no-cache-dir -r /tmp/requirements.txt

WORKDIR /app

RUN <<EOF cat >> main.py
# Taken from https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html#entries
from celery import Celery
from celery.schedules import crontab

app = Celery()

@app.on_after_configure.connect
def setup_periodic_tasks(sender, **kwargs):
    # Calls test('hello') every 10 seconds.
    sender.add_periodic_task(10.0, test.s('hello'), name='add every 10')

@app.task
def test(arg):
    print(arg)

@app.task
def add(x, y):
    z = x + y
    print(z)
EOF

CMD ["python", "/app/main.py"]

From here, iteratively tweak the Dockerfile until you can either reproduce the issue (and you’ll know what step caused it).