Thanks to Tiziano my tinderbox is now running on a Linux container rather than in a chroot. After this statement, let me clarify.
The tinderbox (which, I remember, is just a setup that tries to merge all the packages in the Portage tree) has been making my standard system (Yamato) quite unstable from time to time; this was mostly due to the fact that there was no isolation between the standard system and the tinderbox, and a pkill or killall too much would have broken stuff badly. At the same I couldn’t run init scripts for the same reasons.
Enters Linux Containers (lxc) (that is available on Tiziano’s overlay for the curious): something similar in concept to vserver, but without requiring special kernels, just a few extra options in the standard gentoo-sources kernel. This really looked promising so I decided to try the conversion.
Now, the lxc support is very new, and even Tiziano just played with it, like I’m doing, it’s nowhere near supported when compared to openvz or vserver itself, but it can be made to work. I guess a few more changes to openrc or baselayout should bring it to a production-grade level. For now it works well enough to run the tinderbox. It has quite a few of advantages for me at that point:
- it starts and stops “properly” instead of using my
enter-chrootscript and its bookeeping of mounts; - the pids inside the tinderbox are isolated, so a wrong
killallorpkillfrom the inside out cannot disrupt my system (but ashutdownwould, it seems); - the network is also isolated, which means I can have testsuites trying to open ports like 8000 or 4000 that are usually busy with my real services;
- I can start services like it was a virtual machine;
- I can limit the amount of memory or cpu time(or the actual cpus) used by the tinderbox, so that it cannot freeze my running system;
- it does not require me to statically partition the memory or the hard disk space, since it uses the same kernel as the host system, and thus the same resources;
- it does not stop or die with my user session;
On the other hand, this creates some problems because it also means I need a basic working system there, which means that I cannot let some packages be unmerged for blockers, and I have to make sure that at least some basic configuration data is processed properly. On the other hand this is not really important, since the basic packages should most likely not be unmerged on standard systems, so that’s fine.
Interestingly enough, by the way, I was able to find some new bug categories too! Broken or suboptimal init scripts are the first that happens: stuff with syntax errors in the file (which thus fail to parse), wrong dependencies, or, worst of all, global-scope calls… which are just as bad as global scope in ebuilds, since it takes extra time (and extra work) just to get the dependency cache updated.
But since I only slept four hours last night (neighbor woke me up early this morning!) I’ll be going to nap a while now, and be back later, hopefully writing something about the pam_namespace rejection.