Bug 260248 - jails: depend parameter does not work in modular jail files (conf.d)
Summary: jails: depend parameter does not work in modular jail files (conf.d)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on: 233310
Blocks:
  Show dependency treegraph
 
Reported: 2021-12-06 02:46 UTC by Rocco
Modified: 2023-07-29 02:42 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rocco 2021-12-06 02:46:37 UTC
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.
Comment 1 commit-hook freebsd_committer freebsd_triage 2021-12-15 03:48:52 UTC
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(-)
Comment 2 Rocco 2022-01-14 17:36:39 UTC
(In reply to commit-hook from comment #1)

This changes seems irrelevant to the bug report. It is probably a typo.
Comment 3 Antranig Vartanian 2022-03-29 21:34:05 UTC
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.
Comment 4 Mark Felder freebsd_committer freebsd_triage 2023-03-08 15:21:01 UTC
(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.
Comment 5 Rocco 2023-03-10 06:50:29 UTC
(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.