Should killed process deref a jail?

[Kyle Evans]

On Wed, May 6, 2020 at 1:42 PM Kyle Evans <kevans at freebsd.org> wrote:
>
> Hi,
>
> In doing some testing of qemu-user-static recently, I noticed that
> killing the last process in a non-persist jail doesn't kill off the
> jail:
>
> root at viper:/usr/src# jail -c path=/ command=yes
> ## ^C out
>
> root at viper:/usr/src# jls
>    JID  IP Address      Hostname                      Path
>    181                                                /
>
> root at viper:/usr/src# ps fxJ 181
> PID TT  STAT TIME COMMAND
>
> As a result, I ended up with 82 jails pointed at my armv7 sysroot and
> much surprise when I checked out `jls`. This vaguely smells like a
> bug, is this something that should be fixed?
>

I wrote a small utility to workaround this behavior:
https://git.kevans.dev/kevans/quickjail

I hope to quickly deprecate it with this review or something similar,
if it seems reasonable: https://reviews.freebsd.org/D24745 -> my
problem is entirely centered around sending ^C to the jail command=
that's hanging, which sends SIGINT to the entire foreground process
group, thus killing jail(8) in the process and preventing the cleanup
that should happen when the command terminates.

I think it's perhaps reasonable to just ignore SIGINT and let the
child deal with it or terminate to let jail(8) cleanup afterwards.
Perhaps the surface area in that review that's ignoring SIGINT (read:
the whole thing) is too large, but this is an exercise left up to
someone way more familiar with jail than I am.

Thanks,

Kyle Evans