Open MikaelElkiaer opened 2 weeks ago
The issue is that service_completed_successfully
applies to starting container, not creating.
Compose creates both container with-config
and volumer
but will delay the former one after the latter completed.
As volume is fresh new the target subpath doesn't exists so engine fails to create container.
There's no way to manage this in Compose by this time
How does that explain the fact that the volume submount works without the config and only breaks for the service with?
Oh, and also the fact it is only a problem when starting a 3rd service which depends on the service with a config?
I can reproduce without relying on a 3rd service:
machin docker compose up with-config
[+] Running 3/0
✔ Network machin_default Created 0.0s
✔ Volume "machin_tmp" Created 0.0s
✔ Container machin-volumer-1 Created 0.0s
⠋ Container machin-with-config-1 Creating 0.0s
Error response from daemon: cannot access path /var/lib/docker/volumes/machin_tmp/_data/volume: lstat /var/lib/docker/volumes/machin_tmp/_data/volume: no such file or directory
How does that explain the fact that the volume submount works without the config and only breaks for the service with?
I guess the root cause is collision between /tmp/config.txt
and /tmp/volume
, as engine tries to define mount options.
This is not a Compose issue: can be reproduced with plain docker run
command:
$ docker run --mount source=tmp,target=/tmp/volume,volume-subpath=volume alpine ls -al /tmp
docker: Error response from daemon: cannot access path /var/lib/docker/volumes/tmp/_data/volume: lstat /var/lib/docker/volumes/tmp/_data/volume: no such file or directory.
I guess the reason you only detect this with a config
set is that, as Compose relies on docker cp
to create this config, the engine need to create the mounts for the container (which it uses to do only on start
). When you dont, and have a dependency on volumer
then the target subpath is created by volumer container then service starts and mounts are ok
Any suggestions on how to move forward? Is this behaviour that could be changed?
Any suggestions on how to move forward?
Would need to better know your actual use-case to offer guidance.
Is this behaviour that could be changed?
This may have impacts so I can't tell. As a workaround, you can consider using a plain file as config, which would result into a bind mount
An actual fix would require to change up
implementation so that it creates and start containers before it creates dependent ones. This would have impact on the UX as then we can't display the progress UX as such an initial container would dump logs to the console, still this is something to consider
Description
There seems to be some strange interconnections between volumes and configs, when starting a service as a dependency.
A service with a submount can start fine when running on its own - even when defining a config. But starting a service that depends on the service with a submount will make the dependent service fail - if a config is defined for the dependent service.
Steps To Reproduce
Running this compose file:
will fail if you run
docker compose run --rm with-config-too
, while it works when running any other service. Remember todocker compose down --volumes
when running different services.Compose Version
Docker Environment
Anything else?
No response