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 [EMAIL PROTECTED]
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
