Date: Wed, 17 May 2023 21:54:07 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271474 Bug ID: 271474 Summary: Possible to "lose" a tap(4) interface in a jail Product: Base System Version: 13.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: firstname.lastname@example.org So after some trial and error, I have discovered that it is possible to literally "lose" a tap(4) interface inside of a jail during shutdown if the conditions are right. I am trying to run bhyve within a VNET jail, and thought I would be OK to create 'tap0' inside the jail itself via /etc/rc.conf rather than at the host level and passing it in via VNET. This kinda works for the most part, but in the process of trying to work out how to get bhyve to run inside of a jail, I had to start/stop the jail several times. In one of those instances, I forgot to run "bhyvectl --vm=foo --destroy" before I ran "jail -r foojail". The jail shutdown like it should, then when I went to run "jail -c foojail", I noticed in the console output that it was unable to create the 'tap0' interface because it already existed. Dropping into the jail, 'ifconfig' showed no visible 'tap0' interface. Same at the host level. Somewhere in kernel memory, though, there was a 'tap0' interface with no way to get at it. Doing a proper shutdown of the bhyve instance did not release it, nor did restarting the jail. Only a full system reboot got things back to normal. That's the problem description, anyways. As for a fix, I honestly don't have a good suggestion. Starting and stopping of jails is really just being clever with shell scripting in /etc/jail.conf, so it would be really hard to handle a case where jail shutdown can catch a failure to stop an interface and return that back to 'jail' and have it abort the shutdown. For me, I decided to play it safe and moved the creation of the tap(4) interface to the host level and then just pass it to the jail as a vnet.interface parameter. -- You are receiving this mail because: You are the assignee for the bug.