Date: Sun, 21 May 2023 17:59:55 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 271474] Possible to "lose" a tap(4) interface in a jail Message-ID: <bug-271474-7501-uFXt9hxCao@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271474-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-271474-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271474 --- Comment #2 from Joshua Kinard <freebsd@kumba.dev> --- (In reply to Meyser+bugs.freebsd.org from comment #1) > /etc/rc.d/netif is NOT invoked inside vnetjails. (novnetjail Keyword) > so cloned interfaces are NOT destroyed during shutdown. >=20 > After changing exec.stop in /etc/jail.conf to >=20 > exec.stop =3D "/bin/sh /etc/rc.d/netif stop; /bin/sh /etc/rc.shutdown"; >=20 > cloned interfaces are destroyed before shutdown. >=20 > Perhaps this works in your case too. It looks like "nojailvnet" actually means "allow vnet jails", according to = the rc(8) manpage. The wording for that rc keyword could've been chosen better, IMHO, but in my case, I am using a VNET-enabled jail to run bhyve in. So I don't think this is the exact cause. Rather than keep running this experiment on my production appliance, I dug = an older appliance out of a box and setup a clone of the production appliance's filesystem on it to use as a toy, and tried to re-replicate the case where = tap0 was getting "lost", but so far, I have no been able to find a reproducible cause. Stopping the jail while bhyve was running and then trying to restar= t it kinda-reproduced my initial scenario where netif was unable to create tap0 = on jail start-up, but simply destroying the "dead" bhyve instance from the host-level, then restarting the jail cleared that and tap0 could be re-crea= ted. So I am a bit stumped how I originally triggered this fluke in a way that w= as unrecoverable w/o a reboot. That said, dropping the jail w/ bhyve running = will still create a point where the handle for tap0 is still held by bhyve and t= hus, it can't be recreated next time the jail is restarted until the bhyve sessi= on is destroyed at the host level. So that might be a good debugging point for someone to look into the tap(4) driver to see if there's a way to mitigate this. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271474-7501-uFXt9hxCao>