On 06/28/10 08:24, Alexander Leidinger wrote:
Quoting Jamie Gritton <[email protected]> (from Thu, 24 Jun 2010
10:30:42 -0600):
On 06/24/10 06:43, Alexander Leidinger wrote:
>>
Jails that exist outside of the config file's knowledge are a tricky
point, and the problems are really only on a shutdown request. While I
haven't coded this part of things yet, I've considered that I'll need
two different kinds of blanket shutdowns: one for all the jails in the
config file, and another for all jails in the system. The latter would
be the most sensible to use during system shutdown, when it doesn't make
sense to leave any jails running. But orderly shutdown is part of the
config spec (e.g. running "/bin/sh /etc/rc.shutdown"), and it may be
best to assume that if the jails were created outside of the rc system,
they'll be removed in the same way.
There are two additional sides:
1) For jails which are created by example via ezjail I agree that it is
within the responsability of the ezjail to shut them down.
2) For jails which are created/started by hand from a custom config file
for testing purposes, I think a "shutdown all remeaining jails even if
there is not entry in the config file" would be good. The problem with
this is, that you need to make assumptions how to do a shutdown, or
record this info in the kernel on creation time (and use this only if no
config with appropriate info is available).
If any jails are left on shutdown by the time rc.d/jail gets to them,
they would have to be summarily killed. I wouldn't want to make
assumptions about scripts and the like in the absence of the config
lines, since I assume there's a reason they weren't started withing the
jail.conf system.
When you remove a jail via jail_remove(2), it sends a SIGKILL to every
process inside it. I could at least first send them a SIGTERM and give
them a little while to clean up first. But I still wouldn't to run a
script that wasn't specified by the jail creator, which is at this point
necessarily unknown.
So yes, I'd have a "shutdown all jails" option for this.
- Jamie
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[email protected]"