When using multiple modular jail.conf files under /etc/jail.conf.d it is not possible at the moment to make one jail depend on another. The depend parameter does not work across the different jail.conf files. How to reproduce: - Create two jails in separate files: /etc/jail.conf.d/j1.conf and /etc/jail.conf.d/j2.conf - Make one of the jails (j1) depend on the other (j2) - Call "service jail start j1" Expected output: - The jails are started in the correct order: j2, then j1. Actual output: - The command fails with the error that jail "j2" is not found. Workaround: The sysrc variable "jail_list" can be used to define in which order the jails should be started and stopped. It would be better though to let jail calculate the order.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f349bd910c630dfce390ae347632827aefba34e2 commit f349bd910c630dfce390ae347632827aefba34e2 Author: Derek Schrock <dereks@lifeofadishwasher.com> AuthorDate: 2021-12-11 23:29:23 +0000 Commit: Neel Chauhan <nc@FreeBSD.org> CommitDate: 2021-12-15 03:47:39 +0000 mail/mutt: Update to 2.1.4 Changes: https://marc.info/?l=mutt-users&m=163926095306375&w=2 PR: 260248 mail/mutt/Makefile | 2 +- mail/mutt/distinfo | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
(In reply to commit-hook from comment #1) This changes seems irrelevant to the bug report. It is probably a typo.
Hey @Rocco, can you try doing the same thing with /etc/jail.{jname}.conf? I wonder if it works in that case. If it does, then there's an issue in jail.conf.d, if it doesn't then there's an architectural issue that needs a deeper look.
(In reply to Antranig Vartanian from comment #3) I've tested both cases and they fail. If you run it as sh -x /etc/rc.d/jail start JAILNAME you can see what it's doing. At no point does it attempt to read in any other jail configurations before processing the target jail. This is a bit of a chicken-and-egg scenario as the code handling the startup of jails is shell script which guesses where the jail configs are, and the actual processing of the jail config parameters is done by the C code. A bad hack could be implemented in /etc/rc.d/jail to actually read the contents of these files and look for a "depend =" or "depend +=", parse it, and then try to load /etc/jail.JAILNAME.conf or /etc/jail.conf.d/JAILNAME.conf so it can be merged together and the jail will be discovered. However, this opens a new can of worms as there won't be any isolation of configuration between the jails and if the configs are simply concatenated together to be presented to jail(8) you will have issues with one jail config declaring settings outside the JAILNAME { } section and leaking into the config of the jail that was appended. The correct way to solve this would be to move more logic into jail(8) so it does all of this work for us and /etc/rc.d/jail is stripped down to simply passing start/stop/restart commands to jail(8) similar to how docker works. I will gladly contribute to a bounty to overhaul jail(8) if anyone out there is willing and capable.
(In reply to Antranig Vartanian from comment #3) I can confirm the observation of Mark Felder. Also, looking at the source code there does not seem to be any difference. Unfortunately, fixing this would require some architectural change. Either all jail configurations must be read first before execution starts, or at least in a lazy fashion at the first encounter of "depends". I assume the first one would be easier to implement and more robust.