Skip to content

Commit

Permalink
Workaround for a bug with overlayfs (used on Docker Hub)
Browse files Browse the repository at this point in the history 
* Overlayfs has some weird quirks regarding opening files which leads to <PROTECT> errors when trying to start Cache in a new RUN context while running a docker build
* Touching the CACHE.DAT files triggers the copy-up operation for overlayfs (and does nothing on other filesystems) which allows Cache to read the files properly
* If you think this is weird - it is, but the yum package manager had exactly the same problem and solved it in the exact same way (see the yum-ovl plugin)
  • Loading branch information
@Novex
Novex committed Nov 9, 2016
1 parent 387fafa commit d0bd70f
Show file tree
Hide file tree
Showing 2 changed files with 16 additions and 0 deletions.
7 changes: 7 additions & 0 deletions dockerfile/Caché+SSH/Dockerfile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,13 @@ COPY cache.key $ISC_PACKAGE_INSTALLDIR/mgr/
ENV WRC_USERNAME=""
ENV WRC_PASSWORD=""

# Workaround for an overlayfs bug which prevents Cache from starting with <PROTECT> errors
COPY ccontrol-wrapper.sh /usr/bin/
RUN cd /usr/bin && \
rm ccontrol && \
mv ccontrol-wrapper.sh ccontrol && \
chmod 555 ccontrol

# TCP sockets that can be accessed if user wants to (see 'docker run -p' flag)
EXPOSE 57772 1972 22

Expand Down
9 changes: 9 additions & 0 deletions dockerfile/Caché+SSH/ccontrol-wrapper.sh
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
#!/bin/bash

# Work around a werid overlayfs bug where files don't open properly if they haven't been
# touched first - see the yum-ovl plugin for a similar workaround
if [ "${1,,}" == "start" ]; then
find / -name CACHE.DAT -exec touch {} \;
fi

/usr/local/etc/cachesys/ccontrol $@

6 comments on commit d0bd70f

@zrml
Copy link
Owner

@zrml zrml commented on d0bd70f Apr 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Novex Thanks for this BTW... I had forgotten it and it bit me on my Mac! :-o

@daimor
Copy link
Contributor

@daimor daimor commented on d0bd70f Apr 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same was for me when I worked on an article, I could not start Caché.
That's why I included a part about it in my article.
For me, I've switched Docker to AUFS, and now everything is OK.
Because with overlayfs, needs much more complete workaround. Some changes need in ccontrainermain to touch cconsole.log, as well.

@Novex
Copy link
Contributor Author

@Novex Novex commented on d0bd70f Apr 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries! It took me long enough to work it out - wasn't going to let anyone else go through that pain if I could help it ;)

@daimor, if further workaround is required (eg. touching every file rather than just the CACHE.DAT's) it'd be great if you could contribute an update :)

@daimor
Copy link
Contributor

@daimor daimor commented on d0bd70f Apr 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it, and even had a try to touch all files in instance directory, but it takes some time before container could start. And in this way, we still have to use the workaround like yours, in ways when we should start the instance in a BUILD process later, like to install some application. And even I'm still not sure is it a good way. So, I've just switched to aufs, and it will be enough for some time. And most of the time I'm using Docker on Debian, where I don't have such problem.

@zrml
Copy link
Owner

@zrml zrml commented on d0bd70f Apr 18, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI I'm finding devicemapper very robust since day one and in fact it's the default driver on CentOS 6 RH. I remember we could not write to the JRN file back then ;)
Not sure why Canonical is sticking to overlayfs...
thanks

@zrml
Copy link
Owner

@zrml zrml commented on d0bd70f May 5, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI
CentOS and RHEL use devicemapper by default and I find it reliable for now
while SUSE uses BTRFS (as they do in their root FS). I have heard from a customer they had a terrible time with it. However, according to SUSE, a BTRFS storage-driver should run on a BTRFS filesystem so there might have been issues related to misconfiguration.
see:
https://www.suse.com/documentation/sles-12/singlehtml/book_sles_docker/book_sles_docker.html

It is also worth noting that devicemapper works well on CentOS, RHWL and Ubuntu. I have not tried it on SUSE.

Please sign in to comment.