Re: Unable to stop a jail
At jail2 homepage has link to jail2 tools. http://docs.freevps.com/doku.php?id=freebsd:index link to http://docs.freevps.com/doku.php?id=freebsd:tools Tools allow some resource control. В Пнд, 04.12.2006, в 15:11, Steven Hartland пишет: > Alex Lyashkov wrote: > > Sorry for later response, > > > > this not are corruption - in difference with jail, jail2 need to be > > call > > jctl --ctx $id --destroy for destroy kernel context. > > jctl is not a valid command here, perhaps its a thirdparty addon > you have there? > > 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]"
Re: Unable to stop a jail
Neo-Vortex wrote: Steven Hartland Wrote, jctl is not a valid command here, perhaps its a thirdparty addon you have there? # whereis jail jail: /usr/sbin/jail /usr/share/man/man8/jail.8.gz /usr/src/usr.sbin/jail Its stock on my machine... Perhaps your path is bad? Thats jail not jctl which was the command referenced 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]"
Re: Unable to stop a jail
Steven Hartland <[EMAIL PROTECTED]> Wrote, jctl is not a valid command here, perhaps its a thirdparty addon you have there? Steve # whereis jail jail: /usr/sbin/jail /usr/share/man/man8/jail.8.gz /usr/src/usr.sbin/jail Its stock on my machine... Perhaps your path is bad? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to stop a jail
Alex Lyashkov wrote: Sorry for later response, this not are corruption - in difference with jail, jail2 need to be call jctl --ctx $id --destroy for destroy kernel context. jctl is not a valid command here, perhaps its a thirdparty addon you have there? 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]"
Re: Unable to stop a jail
Sorry for later response, this not are corruption - in difference with jail, jail2 need to be call jctl --ctx $id --destroy for destroy kernel context. В Птн, 01.12.2006, в 12:43, Steven Hartland пишет: > We've got a jail here which we cant stop with either killall > jexec or jkill all return success but jls still reports > the jail as running. > > The machines running several other jails which I cant restart > at this time so I ended up starting the jail again jls > now reports: > jls >JID IP Address Hostname Path > 9 10.10.0.5 jail6/usr/local/jails/jail6 > 7 10.10.0.5 jail6/usr/local/jails/jail6 > 6 10.10.0.4 jail5/usr/local/jails/jail5 > 5 10.10.0.39jail4/usr/local/jails/jail4 > 3 10.10.0.6 jail3/usr/local/jails/jail3 > 2 10.10.0.8 jail2/usr/local/jails/jail2 > 1 10.10.0.7 jail1/usr/local/jails/jail1 > > Host machine is running FreeBSD-6.1-P10 > > Any ideas some sort of kernel data corruption? > > 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]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to stop a jail
On Fri, 1 Dec 2006, Steven Hartland wrote: 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? Well, there are two things going on here: (1) Jails that last a long time due to being referenced by data structures that last a long time. I.e., time-wait TCP connections. (2) Leaks in credentials or jails resulting in jails that never go away. What I describe is intended to address the former issue, which is one that exists for a reason. The latter issues are clearly bugs and just need to be fixed. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to stop a jail
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]"
Re: Unable to stop a jail
On Fri, 1 Dec 2006, Bjoern A. Zeeb wrote: On Fri, 1 Dec 2006, Steven Hartland wrote: We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? no the jails should really be gone (you should not find any sockets or processes for them after some seconds) - at least it should be that way... See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 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. 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. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to stop a jail
On Fri, 1 Dec 2006, Steven Hartland wrote: Hi, We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? no the jails should really be gone (you should not find any sockets or processes for them after some seconds) - at least it should be that way... See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to stop a jail
On Fri, 1 Dec 2006, 10:43-, Steven Hartland wrote: > We've got a jail here which we cant stop with either killall > jexec or jkill all return success but jls still reports > the jail as running. > > The machines running several other jails which I cant restart > at this time so I ended up starting the jail again jls > now reports: > jls > JID IP Address Hostname Path > 9 10.10.0.5 jail6/usr/local/jails/jail6 > 7 10.10.0.5 jail6/usr/local/jails/jail6 > 6 10.10.0.4 jail5/usr/local/jails/jail5 > 5 10.10.0.39jail4/usr/local/jails/jail4 > 3 10.10.0.6 jail3/usr/local/jails/jail3 > 2 10.10.0.8 jail2/usr/local/jails/jail2 > 1 10.10.0.7 jail1/usr/local/jails/jail1 > > Host machine is running FreeBSD-6.1-P10 > > Any ideas some sort of kernel data corruption? Known bug, discussed several times. IIRC leaked struct ucred. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unable to stop a jail
We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? 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]"
