Hi, currently I work on a system that boots with systemd and is well-described by what is termed "stateless system" in http://0pointer.net/blog/projects/stateless.html. In that system "unit enabling" is not stored persistently, so I introduced to usage of presets to define a policy what needs to be enabled on bootup.
Doing so I realized that this works nice for "ordinary" units, however instantiated units will not get enabled via presets. So there seems to be an "asymmetry" in handling of instantiated services between preset-enabled and manually-enabled (i.e. by means of "systemctl enable ..." command) units. I try to give a tabular summary of what is the current behaviour: This table assumes a unit template [email protected] that has an [Install] section telling how to enable that service (e.g. WantedBy=multi-user.target). Additionally, it defines a DefaultInstance there as well. The unit Y.service is a "plain service", not a template. enable action preset manual comment ----------------------------------------------------------------- enable Y works works non-template case enable X@ works works enables DefaultInstance* enable X@x works not works differing behaviour Footnotes: * DefaultIntance is defined in [email protected], there can be only one such instance I tested this with v222. The question is now if this is intended behaviour or a bug? Personally, I find this confusing, since presets are there to define a (default) policy, whereas unit templates are there for "unit reuse". Two different goals that should "not interfere". Hence my expectation would be that instatiated services should work well with presets as well. Can someone give me some enlighenment here, maybe I did not get the ideas well? Cheers, Vivenzio _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
