Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bind-mounted single files don't stay in sync after inode of file changes on host #6011

Closed
tomfotherby opened this issue May 23, 2014 · 5 comments

Comments

@tomfotherby
Copy link
Contributor

From docker v 0.10.0 changelog:

Allow --volumes-from to be individual files.

When I bind-mount a single file into a container, the file does not stay in-sync between the host and the container.

To reproduce:

  1. You need 2 terminals open.
  2. In the first terminal create a file: echo $(date) > /tmp/test
  3. Check the inode of the file: ls -i /tmp/test
  4. In the other terminal, bind-mount this file into a interactive container: docker run -it -v /tmp/test:/tmp/test ubuntu:trusty /bin/bash
  5. Back on the first terminal (the host), make a change to the file which does not change the inode: echo $(date) >> /tmp/test
  6. In the container, cat /tmp/test and you will see the change. So far so good.
  7. Back on the first terminal (the host), make a change to the file which does change the inode: sed --in-place "s/2014/CHANGED/g" /tmp/test
  8. Notice the inode has changed: ls -i /tmp/test
  9. Problem: In the container, cat /tmp/test and you will not see the change. 👎
    • Expected: The file in the container should show the same as the host. 😎

Use-case: I have ngnix containerised with only the nginx.conf file bind-mounted to the host. I want to change the file on the host (e.g. change the proxy IP address), then send the nginx process a SIGHUP signal (kill -HUP) to reload the config. This doesn't work because when I change the nginx.conf file on the host, the container cant see the changes. Hence I'm opening this issue.


My host info (asked for in guidelines for contributing):

  • host OS: Ubuntu 14.04.
  • uname -a: Linux Pochama 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
  • docker version:
Client version: 0.11.1
Client API version: 1.11
Go version (client): go1.2.1
Git commit (client): fb99f99
Server version: 0.11.1
Server API version: 1.11
Git commit (server): fb99f99
Go version (server): go1.2.1
Last stable version: 0.11.1
  • docker info:
Containers: 24
Images: 1225
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 1273
Execution Driver: native-0.2
Kernel Version: 3.13.0-24-generic
Username: tomfotherby
Registry: [https://index.docker.io/v1/]
WARNING: No swap limit support
@jpetazzo
Copy link
Contributor

jpetazzo commented Jul 3, 2014

That's expected. What happens with sed --in-place is:

  • sed opens a new temporary file in the same directory
  • sed does its job, reading from the original (bind-mounted) file, writing to the new temporary file
  • at the end, sed moves the temporary file over the old one

docker -v x:y doesn't work "by name". If you move x, it remains bound to the container.

We could add a warning to the docs, but there is no way to "fix" this.

@tiborvass
Copy link
Contributor

What @jpetazzo said.

@tomfotherby you could bind mount the directory above, and then sed -i should work.
If you absolutely don't want to bind mount the directory above, you could create a new directory where nginx.conf is, and move nginx.conf in there. If nginx needs nginx.conf where it originally was, you can symlink it. Now just bind mount the newly created directory and you should be good to go.

Not perfect I agree.

@tomfotherby
Copy link
Contributor Author

That's expected

Respectfully, that might be expected by you, but it was not expected by me 😕 . Bear in mind I am more "dev" than "ops" and had to Google what a inode was while debugging and writing up the reproducible steps!

I agree adding a warning in the docs would be absolutely great to avoid future confusion. The current document (https://docs.docker.com/userguide/dockervolumes/) doesn't really mention single-file mounts so maybe they are not recommended anyway?

@tiborvass - thanks for the useful suggestion. As an aside, my use-case for bind-mounting a single file wasn't very smart. I found a better way to modify a file at run time from the host is to expose it as a volume and then run a adhoc docker command that uses --volumes-from to get access to the file I need to modify. This was well documented recently by docker: http://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/

@jpetazzo
Copy link
Contributor

jpetazzo commented Jul 4, 2014

Hi Tom,

Yes, sorry, I didn't mean to dismiss your remark; I was merely trying to explain the "logic" (mark the quotes :D) behind it.

Technically, it might be possible to poll the bind-mount sources and issue a warning when their inode number changes. That would actually be pretty easy, and the resource usage would be negligible. However, I wonder (assuming that we would implement that) where such a warning should show up?

@tomfotherby
Copy link
Contributor Author

docker -v x:y doesn't work "by name". If you move x, it remains bound to the container.

I wanted to test this comment.

First, I tested with a folder:

> mkdir x
> docker run --rm -it -v ~/x:/y ubuntu /bin/bash
> root@7ac7d115a6ae:/# mv y z
mv: cannot move 'y' to 'z': Device or resource busy

Second, I tested with a file

> rmdir x;  touch x
> docker run --rm -it -v ~/x:/y ubuntu /bin/bash
> root@7ac7d115a6ae:/# mv y z
mv: cannot move 'y' to 'z': Device or resource busy
> sed --in-place "s/2014/CHANGED/g" y        
sed: cannot rename ./sedKdJ9Dy: Device or resource busy

OK - this is better!

> docker --version
Docker version 1.1.0, build 79812e3

So I think in the latest version of docker they made some changes and now you get a error so you can't accidentally "break" the bind-mounting. Cool, closing ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants