jails shutdown in the same order they are started. this makes it impossible to have one jail depend on any of the services of another. (for instance, my first jail to start up provides a caching dns resolver that the other jails use) as implemented currently, that jail shuts down first, causing other jails to loose their ability to look up names. if any other jail needs that functionality (or anything provided by an earlier-started jail for that matter) in order to shut down gracefully, it will timeout and often timeout rc.shutdown as well.
Fix: add boolean rc.conf variable jail_reverse_shutdown. reverse jail_list when doing jail_stop in rc.d/jail if it is set to yes. i would argue that the default should be enabled (a la: rcorder in rc.shutdown) but to preserve existing behavior it probably ought to be off by default.
i have been using this small straightforward patch in production for years, and been meaning to kick it upstream for a long time. please get this into 7.4 and 8.1. (if not 7.3-STABLE or 7.3-RELEASE-p?)
Patch attached with submission follows:
How-To-Repeat: create a couple jails. boot multi-user, then shutdown. note the order.
heres an additional patch to the rc.conf manpage to document this feature:
diff -rNU3 ../src.dist/share/man/man5/rc.conf.5 ./share/man/man5/rc.conf.5
--- ../src.dist/share/man/man5/rc.conf.52010-02-10 00:26:20.000000000 +0000
+++ share/man/man5/rc.conf.52010-04-26 16:42:53.000000000 +0000
@@ -3696,6 +3696,11 @@
If set to
.Dq Li YES ,
allow applications within a jail to use System V IPC.
+.It Va jail_reverse_shutdown
+.Pq Vt bool
+If set to
+.Dq Li YES ,
+use the reverse order when stopping multiple jails.
.\" ----- ISDN settings ---------------------------------
.It Va isdn_enable
.Pq Vt bool
Assign to correct mailing list, fix category.
I think my original change request may have been unclear and my example was certainly contrived.
If a user of FreeBSD jails wishes to ensure that for jail A B and C, A and B are always running at any point in time in which C is, it is impossible to do so using the existing rc.conf system because `/etc/rc.d/jail stop` will stop them all, serially, in the same order that `./jail start` started them all.
In the EXISTING implementation, for rc.d scripts "a b jail f" (as a list output by rcorder(8)), and jails "C D E":
rc does basically something to the effect of: `./a start; ./b start; ./jail start C; ./jail stop D; ./jail stop E; ./f start`
while rc.shutdown then later does something to the effect of: `./f stop; ./jail stop C; ./jail stop D; ./jail stop E; ./b stop; ./a stop`
but I PROPOSE that the rc.shutdown process should instead result in: `./f stop; ./jail stop E; ./jail stop D; ./jail stop C; ./b stop; ./a stop`
If no one seems to care and there is no one worrying about their jails' shutdown order, IMHO we should just quietly add the single important line of my patch to rc.d/jail:
echo -n 'Stopping jails:'
and not clutter up rc.conf any more with this jail_reverse_shutdown boolean. But, the patch i originally provided will add this rc.conf variable while allowing existing behavior to remain the default.
Just because we are not meta-data gathering and automatically dependency sorting the jails for the user (a la what rcorder does with the rc.d scripts) doesn't mean we shouldn't reverse that jail_list for them when it comes time to shutdown, (like rc.shutdown does to the dependency-sorted list of rc.d scripts that are output from rcorder,) since the user may have ordered their jail_list manually for dependency reasons, and some dependencies may be required all the way through shutdown for a particular servi ce.
reversing the jail list in jail_stop also affects manual use of the jail rc.d script on the command line such as `./jail start A B C` and `./jail stop A B C`. the jails should still be listed in dependency order on the command line because jail_stop will reverse the list when stopping them.
the cool new jail features in 9.1 release now include ACTUAL dependency =
sorting using the 'depend' parameter.
If someone wants to close this PR, that'd be fine.=
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped