[Bug 267315] dangling jail references

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267315

            Bug ID: 267315
           Summary: dangling jail references
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: markj@FreeBSD.org

Some operations in jails cause the jail to get stuck in the DYING state,
holding onto memory resources.  This makes it difficult to write regression
tests using jails, particularly with nested jails.  With nested jails, I
*think* the fact that the child gets stuck prevents the parent from
auto-destroying itself when the last process exits.  But this means that test
cleanup doesn't work even if the test passes.

I can reproduce one case easily:

markj@biggie> sudo jail -c name=test vnet command=sh
# ifconfig lo0 up
# ^D

At this point the jail is supposed to go away since it isn't persistent and
doesn't contain any processes.  But jls shows that it's still there:

    20                                /
        test                          DYING
        30

If I don't UP lo0, then it works as expected.

Here's a more involved example:

markj@biggie> sudo jail -c name=test children.max=1 vnet command=sh
# ifconfig lo0 up
# ifconfig lo0 inet 127.0.0.1
# jail -c name=test ip4.addr=127.0.0.1 command=sh
# exit
# jls -vd
   JID  Hostname                      Path
        Name                          State
        CPUSetID
        IP Address(es)

So far so good, but then if I try to create a connection:

# jail -c name=test ip4.addr=127.0.0.1 command=sh
# nc 127.0.0.1 8080
# echo $?
1
# exit
# jls -vd
   JID  Hostname                      Path
        Name                          State
        CPUSetID
        IP Address(es)
    32                                /
        test                          DYING
        39
        127.0.0.1

Then upon exiting the parent jail, it remains in the ACTIVE state, so I have to
manually destroy it.

-- 
You are receiving this mail because:
You are the assignee for the bug.