Unable to stop a jail

Steven Hartland killing at multiplay.co.uk
Fri Dec 1 03:42:24 PST 2006


Robert Watson wrote:
> Not all cases of straggling jails are leaks -- does netstat -n show
> that all the TIME_WAIT TCP connections in the jail have been GC'd? 
> Because security state may be used in the network stack for TCP
> packet transmission/reception, the ucred remains referenced until the
> last socket/pcb associated with it are free'd.  I've been wondering
> if we should add a jail process counter, and hide jails in jls if the
> counter is zero (with a -a argument or such to show them). One idea
> I've been kicking around is adding a zombie state for jails, in which
> some straggling references exist, but (a) there are no processes in
> the jail, and (b) no new processes are allowed to enter the jail. 
> The significance of (b) is that we could vrele() the vnode reference
> hung off the jail; there's been at least one report that this vnode
> reference causes issues, as the file system it's from can't be
> unmounted until the last jail reference evaporates.

This appears to not be the case here as there where no references
to the address in netstat and no processes remaining. So it does
seem there is some sort of leak still remaining there someone
where.

At one point I did have two "zombie" jails ( of the same jail )
but the second one was due to a socket reference which then
just disappeared a minute or so later.

> In essence, this would move to having two reference counts on the
> prison: a "strong" reference that has to do with having process
> members, and a "weak" reference that has to do with ucreds pointing
> at the prison. 

The proposal sounds like a good idea but I'm sure there's an argument
that would say thats just hiding the real underlieing issue?

    Steve


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.



More information about the freebsd-hackers mailing list