I’ve been using Linux Containers (LXC) for quite a while, and writing about it — in the mean time the Control Group feature in the Linux kernel has grown to be used in so many different ways, that probably a number of people weren’t really expecting, such as the systemd and OpenRC integrations.
I’ve set up another LXC host system here when I’m working so I can share a single box for multiple purposes without risking to contaminate the different components (there is more to this but I’ll get to it later), in a manner vaguely reminiscent to what ChromiumOS does for its own builds.
One of the things we’ve been dealing with is the problem of synchronising the userids so that they are kept the same across the different containers, and for that the first obvious solution that came to my mind is to use a bind mount on a file. If you didn’t know it’s possible, well, you now know it is. A bind mount on a file allows you to make a given file from the host system appear as a file within the container, and just that one file, rather than the whole directory that contains it.
Unfortunately, it doesn’t work as many suppose it works. It’s neither like a symlink nor a hardlink, although the latter is probably the closest idea you can have of it.
When you have a file that has two hardlinks (so two references on the same filesystem), the changes between the two are reflected as long as you replace the content of the file and not the file itself. This is very important, and a very long time ago, before GIT and Quilt became popular, it was used to make patching software trees easier — you created an hardlinked copy of your sources, edited the files you needed, then diff -uR would just skip over the same-content hardlinks without caring. This method relied on editors to break the hardlinks by using a sequence of operations along the lines of “rename the current copy to act as a backup, write a new file with the same name, done”.
What happens with bound files is that if you editor works in the same way, the bound file is renamed, and a new, non-bound file is created in its place, which means that the changes within the LXC host will not be reflected outside of it, and the same goes for the changes done outside: if you want for them to be reflected inside you have to reboot the container.
So you can probably use this trick if your files are to be edited with either Emacs or VIM, since both of them, by default and in normal circumstances (Emacs via tramp will not preserve hardlinks!), seem to work just fine — where the trouble starts is when you’re dealing with utilities in the shadow family since they will break hardlinks for you.
So there you go for what concerns this part of containers’ usage.