On Thu, 06.08.15 12:10, Vivenzio Pagliari ([email protected]) wrote:
> 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? Yes, the preset logic does not cover what you are trying to do. It works by iterating through the available unit files, and then matching them against the preset file, not the other way round, how it would be necessary for what you are trying to do. What you can do is use the Alias= setting in the [Install] section to create multiple symlinks: for example, if you write a unit file [email protected] you could add this to it: [Install] Alias=multi-user.target.wants/[email protected] multi-user.target.wants/[email protected] And so on... THat said, I think we really should change DEfaultInstance= to take a list of instances, not just one... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
