Open benibr opened 6 months ago
One more thing: The reason for the $TEST_PATH
variable is, that it is used like this in the production setup. However, there the path gets expanded to a full path somehow leading to an error message in case of failure looking like:
Error response from daemon: failed to populate volume: error while mounting volume '/var/lib/docker/volumes/docker-migrid_vgrid_files_readonly/_data': failed to mount local volume: mount /opt/migrid/docker-migrid/state/vgrid_files_writable:/var/lib/docker/volumes/docker-migrid_vgrid_files_readonly/_data, flags: 0x1001: no such file or directory
I'm not able to reproduce the error that way, if I set TEST_PATH=.
in my test script, it always fails with an unexpanded error message like this:
Error response from daemon: failed to populate volume: error while mounting volume '/var/lib/docker/volumes/tmp_subdir/_data': failed to mount local volume: mount ./parent/bar:/var/lib/docker/volumes/tmp_subdir/_data, flags: 0x1001: no such file or directory
Not sure how that fits into the whole picture though.
Can you please clarify the need for second volume subdir
as this one is already nested inside a volume and is mounted inside container as same subdir?
Also, as you compare this with a plain docker run...
command, please note your compose file declares a volume, not just a bind mount which doesn't make it a strict equivalent. Do you really need a volume here? Can't you just define bind mounts in your compose file?
Can you please clarify the need for second volume
subdir
as this one is already nested inside a volume and is mounted inside container as same subdir?
As I said, I agree that this is not optimal. There isn't any necessity to have those nested volumes, but the config occurs like this due to a default setting. The production compose file of the application defines a volume with application state, inside there is a cache folder. Recently the devs wanted to have that state directory configurable so that one can set it to eg. a tmpfs directory. So they defined a sperate volume, which per default just points to inside the already existing state volume but might be overwritten by the users with another path.
Also, as you compare this with a plain
docker run...
command, please note your compose file declares a volume, not just a bind mount which doesn't make it a strict equivalent. Do you really need a volume here? Can't you just define bind mounts in your compose file?
Yes in the current setup the volume in necessary as it must be populated with as directory tree at first start.
I'm aware that there are ways to work aroung this but since the behavior of this particular case is inconsistent and might change with every run, I thought I report it as a bug to save others the time to dig through it again.
Yes in the current setup the volume in necessary as it must be populated with as directory tree at first start.
right, but in your docker run ..
reproduction example you don't use such a volume but a simple bind mount. So my question: can you get the same behavior using docker volume create ...
the use created volumes to run a container?
I believe #11706 is related as overlapping configs/volumes will also trigger a race condition.
Yes in the current setup the volume in necessary as it must be populated with as directory tree at first start.
right, but in your
docker run ..
reproduction example you don't use such a volume but a simple bind mount. So my question: can you get the same behavior usingdocker volume create ...
the use created volumes to run a container?
I tried it, but it's not exactly the same. With plain docker I couldn't get it to succeed. It always fails but sometimes it complains about being not able to chmod the subdir and sometime it complains about not being able to mount the subdir cause it doesn't exist.
docker: Error response from daemon: failed to chmod on /var/lib/docker/volumes/rc-subdir/_data: chmod /var/lib/docker/volumes/rc-subdir/_data: read-only file system.
docker: Error response from daemon: failed to populate volume: error while mounting volume '/var/lib/docker/volumes/rc-subdir/_data': failed to mount local volume: mount /tmp/parent/subdir:/var/lib/docker/volumes/rc-subdir/_data, flags: 0x1001: no such file or directory.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Description
We have a customer setup where a volume is bind mounted into a container and the container populates it with some files on first start. Later another volume was added which is a subdirectory inside the first volume. This subdirectory gets created by the file population of the container at first start. Now I'm aware this is not a really self consistent concept and therefore might be bad practice, however the problem is that is sometimes fails and sometime succeeds which is worse then just getting a error.
Steps To Reproduce
I tried to stay a close to the original setup as possible while removing everything which is not necessary. This is what I came up with to reproduce:
Since this is a race condition it might behave differently on other systems depending on CPU,IO,etc. You can play around with the parameters in search for the "sweet spot". I did not find any config that always fails, but some that are more likely to succeed more often %)
Compose Version
Docker Environment
Anything else?
I'm posting this here because I'm not able to reproduce this with Docker alone. Eg.
mkdir -p state; rm -rf state/* state/.*; docker run --rm -ti -v ./state/log:/var/log -v state:/var debian bash