Next: The tomloader command, Previous: Tomloader, Up: Tomloader   [Contents][Index]

---

1 Overview ¶

The primary purpose of Tomloader is to simplify the managment of multiple systemd unit files that share configuration fields.

Systemd already provides native support for configuration reuse through .conf files inside drop-in directories (.d/) which can be hierarchically organized (for example, unit A-B-C.unit inherits all drop-in configurations listed in A-B-.unit.d/ and A-.unit.d/). While useful, it present some limitations:

• inheritance follows a single linear hierarchy, preventing composition from multiple unrelated sources;
• .conf files cannot be templated;
• the final result heavily depends on file ordering inside the drop-in directories, making outcomes sensitive to file naming;
• dependencies between .conf files cannot be explicitly expressed.

Although symlinks may be used the first issue, they do no address the lack of parametrization. Additionally, ordering constraints remain a source of potential misconfiguration even with naming conventions like numeric prefixes.

Tomloader addresses these limitations with the introduction of groups. A group is a collection of systemd configuration fields which may declare dependencies on other groups. Despite .conf files in drop-in directories:

• multiple groups are not allowed to modify the same field, such conflicts are detected and will prevent unit generation unless resolved;
• groups may define parameters that may change the values set by configuration fields;
• group can declare dependencies on other groups.

Groups are loaded during the generation of a systemd unit. When a group is loaded, all its systemd configuration fields are imported into the unit. A loaded group can still be unloaded and all its fields reverted to their original stated. A group can be unloaded because another group providing similar functionalities is loaded and imported in the generated unit, or just because it is loaded as a dependency of another group but it is not needed.

It is not important the order the groups are loaded in the generated systemd unit: the resulting systemd unit will be the same as long as the same groups (with the same parameters) are loaded into.

There are two kinds of dependencies for a group:

• load dependencies: automatically included whenever the parent group is used;
• remove dependencies: explicitly excluded whenever the parent group is used, even if references elsewhere.