On 04/25/13 08:58, Mateusz Guzik wrote:
On Wed, Apr 24, 2013 at 07:40:21PM -0600, Jamie Gritton wrote:
On 04/24/13 19:22, Mateusz Guzik wrote:
On Mon, Apr 22, 2013 at 12:29:38PM -0600, Jamie Gritton wrote:
On 04/22/13 11:39, Miroslav Lachman wrote:
This already happens when jails are created using a jail.conf file. Any
mounts there are unmounted as part of the jail removal process. Just
recently I fixed it to properly do this unmounting in reverse order.
Do you mean mounts defined in jail.conf or all mounts manually done by
root user in jail?
Ah, I see the difference. Yes, that's only for mounts in the jail.conf.
For mounts done by the jail itself, I guess we would go off the mount
record's credential. So is this something you expect to be happening
entirely in the kernel?
If we want to clean this up from userspace, we need to teach the kernel how
to export vnet and mount table of a jail and then it would be nice to teach
jls how to print it (or maybe create a separate tool - jstat?), and of
course jail(8) how to use this information to clean things up.
Bonus points if jail(8) -r is able to clean up the jail without looking at
config file.
I would prefer if the jail would be able to just die if no problems were
encountered and that is easly done with a kernel-only implementation,
but this still would benefit from features described above (the
difference would be that if someone wants to kill the jail, jail(8)
would only call jail_remove). If jail could not die because some clean
up operations failed, jls (or jstat) would show what resources are
remaining along with error message (say, fs could not be unmounted
because it was busy). And then the user can fix the problem and do
jail(8) -r to re-run kernel clean up or clean on his own (say, unmount
filesystems), which effectively should kill the jail.
Thoughts?
If the kernel was able to export vnet and mounts, I would want jls to be
the tool to show it. At least I wouldn't want to add another tool; a "-j
jailname" option to df and ifconfig is an intriguing option. If jail(8)
can get this information, then I would definitely want jail -r to clean
it up; it doesn't matter whether or not there's a config file, since
we're talking about things that are done outside the config file anyway.
Lack of precision here, my bad. Clearly, if we just started a jail there
is no problem making it record everything it did.
With bonus points I was thinking about a jail started with, say,
mount.devfs. IIRC jail(8) just mounts devfs but this is not stored anywhere
and when such jail dies, we have an old mount noone knows about. So
bonus points for making a jail able to clean this up as well.
No, jail(8) will properly unmount anything *it* mounts, including devfs.
The only issue is when a jail is started with allow.mount (and perhaps
any allow.mount.foofs), and then mounts its own filesystems.
I'm fine with either jls or jstat.
Vnet's little tricky because there are two kinds of interfaces in a vnet
jail: those that were imported into the jail, and those that the jail
has created itself. I don't know if the kernel knows anything about the
difference between them, but it would make sense for the former to be
returned to the host (which is the case) and the latter to be delete
(which I have no idea about).
That's for project taker to invesitage then.
I still prefer that this be done in the kernel. For example, mount
points have a credential attached, and that means that a removed jail
will stick around as a zombie until it's unmounted.
I prefer kernel implementation as well.
Since we seem to have an agreement of usefulness of the project, would
you be willing to add it to IdeasPage as a proposed GSoC project and
mentor a student (if any) who wants to work on this? I'm no fit for
mentoring.
Details of actual implementation can be worked on later.
I'm trying to think if there are cases where this isn't the desired
outcome, where someone might want to purposefully create a jail that
leaves things mounted and then goes away. I can't come up with anything
offhand, but then I sometimes get surprised by how people want to use jails.
- Jamie
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[email protected]"
