I’ve ran into a few problems with docker I’d like to document myself and how to solve them.
Overwriting an entrypoint
If you’ve configured a script as an entrypoint which fails, you can run the docker image with a shell in order to fiddle with the script (instead of continously rebuilding the image):
#--entrypoint (provides a new entry point which is the nominated shell)
docker run -i --entrypoint='/bin/bash' -t f5d4a4d6a8eb
Possible errors you face otherwise are these:
/bin/bash: /bin/bash: cannot execute binary file
Weird errors when building the image
I’ve ran into this a few times. Errors like:
If you’ve set SELinux to enforcing, you may want to temporarily disable SELinux for just building the image. Don’t disable SELinux permanently.
Old (base) image
Check if your base image has changed (e.g. docker images) and pull it again (docker pull <image>)
You hack on a patch, add files to the index and with a knee jerk reaction do:
git commit --amend
(In fact, I do this in my editor with the vim-fugitive plug-in, but it also happened in the terminal). For the commit message git places you in your text editor. If you quit, your changes are merged with the last commit. Being aware of your trapped situation, what do you do?
Simply delete the commit message (up to where the comments start with #). The typical git commit-hook will see it as a commit with an empty message and abort the commit and therefore the merge.
When it comes to a full hard disk in one of your virtual machines, I found this article utterly useful resizing it:
KVM Linux – Expanding a Guest LVM File System Using Virt-resize
Since I’m working with gerrit and following a few best practices from colleagues. Here is one I found very helpful.
A bad commit can happen from time to time, which perhaps addresses only partially a problem. Best practice is to revert the commit, rework it until it fixes the problem. Why? That way you can grab the “right” patch which fixes the specific problem instead of searching for multiple patches and fix of fixes.
How you do it
- Create a branch with bad commit on top (a0eae90 is the SHA of the bad commit):
# puts you in detached head state with a0eae90b45f9b94c3f0742df627eefd864c089c8 at the top
git checkout a0eae90b45f9b94c3f0742df627eefd864c089c8
# checkout new branch with the name fixup/bug_2312312 in order to work on it.
git checkout -b fixup/bug_2312312
- Revert the patch (HEAD~1 == a0eae90):
git revert a0eae90b45f9b94c3f0742df627eefd864c089c8
- Cherry pick the “bad” commit:
git cherry-pick a0eae90b45f9b94c3f0742df627eefd864c089c8
- Unstage the cherry picked commit to work on the patch:
git reset HEAD~1
Kudos to Simon Baird and Peter Hutterer for their help on this.
I just ran into a problem in which I got myself cornered. I’ve edited a configuration file with elevated permission using sudo:
sudo vim /etc/httpd/conf.d/metrics.conf
From time to time when editing, I background the vim session in order to perform some commands in the shell, then continue working in vim. This time, I’ve sent the editor into the background. When trying to foreground it I got this:
~/Metrics(branch:bug_947304*) » fg
 + 11403 continued sudo vim /etc/httpd/conf.d/metrics.conf
 + 11403 suspended (tty input) sudo vim /etc/httpd/conf.d/metrics.conf
What? How? When? Any attempt to foreground this process failed. Reason was the elevated permission I’ve started the editor with. Long story short, you’ll need to kill the editor in order to get back into editing. This mailing list thread explains why.
I’m currently running a few VMs using libvirt under Fedora 19. One problem I ran into with a new workstation was extremely sluggish performance. After consulting the interwebs, I found this great article.
You want to check two things:
- Is your architecture dependent kvm module loaded (e.g. kvm_intel). If not, and you can not load it check your BIOS settings if visualization is enabled.
- Check your VM details under “Overview” which hypervisor is in use: kvm or qemu? Choosing kvm will most likely speed things up.
At Mooball, there are still instances running with a CMFPlone v. 2. Very, very old. Back in the days when Plone v2 was shipped, Python 2.3 was hip and zc.buildout was never heard of.
One motivation I have to deploy with a ZEO is the possibility to pack your database from a simple cron script (which you configure in your buildout too). If you’re still one of them who has to deal with these old instances, here is what you do:
Use Python 2.3
I’ve always compiled my own python 2.3 to avoid any side effects introduced by python installations from the distribution. Version 1.2.1 of zc.buildout works fine for me, the only missing thing is the subprocess module introduced in python 2.4. To get buildout running, I’ve copied subprocess.py from python 2.4 into the python 2.3 installation. After that is done, run the bootstrap with (the -v pins the zc.buildout version to 1.2.1):
/path/to/python2.3/bin/python bootstrap.py -v1.2.1
Run with zc.buildout
I’ve created a sample buildout.cfg and put it up on gist. The important part is the ‘fixup’ which simply comments out 3 keys in the generated config files, which are not supported by the Zope/ZEO version. Depending how much time you have available, play with the options to pin eggs instead of dropping the whole CMFPlone tarball in the products directory. Running the buildout from the products directory is the quickest way tho.