On Wed, 17 Nov 2010, Thierry Herbelot wrote:
The problem has been present since day 1 and is still present up to
HEAD. This is about type stability and teardown. So far we are no
able to actually free TCP (and UDP in SVN) states as they might still
be accesses after "free". It's a general problem in the network stack
and has been implemented as a measure to circumvent panics in those
I am not sure if that's actually what's biting you wrt to memory or
if it's something else. Unfortunately boot logs and kernel configs
don't help much; enable ddb and get show uma and show malloc reports
after the crash (or watch vmstat -z and vmstat -m) after every 50 jail
restarts. I might have some patches for a couple of things but cannot
(yet) help with the additional (duplicate) UMA zones showing up at
each iteration (for the -z case).
The context for our problem is that VIMAGE jails are mant to be used "in
production" for automated tests, thus are likely to be multiple on one
physical host, and are likely to be started and stopped according to our
We have tried more "classical" virtualization solutions (qemu, kvm, ... ,
normal jails with individual FIBs, ...) but only FreeBSD with VIMAGE seems to
be the correct answer. (for other reasons, an i386 version of the kernel must
The point of my original email was to simplify the configuration for a test
setup : any machine with the attached configuration file and the above
sequence of commands creating and deleting jails, running in a loop, will
The thing you can do is start the jails persistent and then only
garbage collect proceses and network configuration manually and
reconfigure/restart things for the next iteration; you might still
leak network stack details between runs but if that's not a problem
for you the solution might work.
Bjoern A. Zeeb Welcome a new stage of life.
<ks> Going to jail sucks -- <bz> All my daemons like it!
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to