The 'stop' (and 'restart') command of /etc/rc.d/jail stops not only jails defined in jail.conf, but *all* jails. I'm not sure whether there's legit reason to run something like ezjail or iocage in parallel to jail.conf jails, but at least with poudriere on the same host, there's a legitimate case for having more than one source of jails and I'd argue it should only stop the jails defined in jail.conf (since it only starts those as well).
Jail definition statements can still be placed in rc.conf which is the pre release 6.0 method or in the jail.conf file which is the new way since release 6.0. The code in rcd/jail needs to be cleaned up removing the processing of the old rc.conf jail definition method. ezjail uses the rc.conf method and gets a warning message telling the user to change his jail definition method to use jail.conf. The ezjail maintainer has been told to update ezjail many times over the past 6 releases of FreeBSD but has not done so. qjail is an updated version of ezjail that uses jail.conf and only starts/stops/restarts jails under it control. It does not use the default jail.conf file so native jails and other jail tools do not step on qjail jails. When it comes to jails with manual defined definitions in the default jail.conf file with other jail tools also putting their jail definitions in the default jail.conf file the rc.conf jail start statement will start all of them at boot time by default as designed. Adding the rc.conf jail names statement containing the jail names to use is only way to control which jails are started at boot time by default. It is the users responsibility that native jail and jail tools that use the default jail.conf file DO NOT exist on the same host at the same time because of the possibility of them stepping on each other during host boot or stop/restart time. To summarize: This is not a bug or short coming in rcd/jail. But a design flaw in some jail tools making them incapable of playing nice with native jails defined in the default jail.conf file. This bug report should be closed because it's not a bug.
I think it's a bit odd to rule that it should be closed with absolutely no action (perhaps documentation at a minimum) to be taken. Having jails while also using tools like poudriere that create transient jails seems like it should be perfectly fine without this rc script stomping on the latter.
While it would make sense for something like poudriere to work with the existing jail.conf setup, that's non-trivial and not urgent. It seems reasonable to add an rc knob for rc.d/jail to not remove all jails, and keep the default behavior as is.
The mention of poudriere reminded me of how /usr/local/etc/periodic/security/410.pkg-audit attempts to audit poudriere jails: * https://github.com/freebsd/pkg/issues/1748 * https://github.com/freebsd/pkg/pull/1749 FYI: $ pkg which /usr/local/etc/periodic/security/410.pkg-audit /usr/local/etc/periodic/security/410.pkg-audit was installed by package pkg-1.13.2 How is this related? They are all hard problems to solve.