Permalink
Browse files

Workaround for a bug with overlayfs (used on Docker Hub)

* 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 committed Nov 9, 2016
1 parent 387fafa commit d0bd70fda2647dfdc9312bf7beefb9df3d1507da
Showing with 16 additions and 0 deletions.
  1. +7 −0 dockerfile/Caché+SSH/Dockerfile
  2. +9 −0 dockerfile/Caché+SSH/ccontrol-wrapper.sh
@@ -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
@@ -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

This comment has been minimized.

Show comment
Hide comment
@zrml

zrml Apr 11, 2017

Owner

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

Owner

zrml replied Apr 11, 2017

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

@daimor

This comment has been minimized.

Show comment
Hide comment
@daimor

daimor Apr 11, 2017

Contributor

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.

Contributor

daimor replied Apr 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Novex

Novex Apr 11, 2017

Contributor

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 :)

Contributor

Novex replied Apr 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@daimor

daimor Apr 11, 2017

Contributor

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.

Contributor

daimor replied Apr 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zrml

zrml Apr 18, 2017

Owner

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

Owner

zrml replied Apr 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zrml

zrml May 5, 2017

Owner

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.

Owner

zrml replied May 5, 2017

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.