On 2015-08-06 12:21:33, ext Lennart Poettering wrote: > On Thu, 06.08.15 12:10, Vivenzio Pagliari (vivenzio.pagli...@nokia.com) wrote: > > > > [... presets] 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. > > > > [...] > > > > 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 X@.service, 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. > > > > 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 > my-little-getty@.service you could add this to it: > > [Install] > Alias=multi-user.target.wants/my-little-getty@foo.service > multi-user.target.wants/my-little-getty@bar.service > > And so on... > > THat said, I think we really should change DEfaultInstance= to take a > list of instances, not just one...
Aliases (or a list of instances accepted as DefaultInstance(s)) may solve the problem. However, I still have a "conceptual problem": If I want to enable cetain instances "by policy", I would like to do so in the preset, but not in the unit file itself. The [Install] section of a unit file describes the enable-behaviour, but not the enable-policy, AFAIU. So from my perspective there would still be a "desire" to use preset as if I would do "systemctl enable ..." by hand. Your argument above describes that preset logic seems to be different from "manual enable logic". Is this an "implemenation detail" or is this deliberately designed so? If it is just impemenation detail, does it make sense to adjust it to work like manual systemctl enable? cheers, Vivenzio _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
