On Thu, 06.08.15 13:22, Vivenzio Pagliari ([email protected]) wrote:
> On 2015-08-06 12:21:33, ext Lennart Poettering wrote: > > On Thu, 06.08.15 12:10, Vivenzio Pagliari ([email protected]) > > 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 [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. > > > > > > > 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... > > 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? Well, the idea is that there's "systemctl preset" that you invoke on a unit, and it then checks if the unit shall be enabled. Then there is "systemctl preset-all" to do this for all installed units. Either way, the unit is the key, and the preset then let's you know the suggested setting. I am open to extending the preset logic to include instance information, but I think I would prefer this a bit differently. Instead of making "enable [email protected]" in the preset value a valid setting (and thus making the preset file the enumeration source) I'd propose instead to extend the syntax to carry lines like: enable [email protected] bar waldo quux This would mean that if "preset-all" is done, and [email protected] is found among the unit files, it shall be enabled for three instances. If you wonder where the effective difference of using the preset files as enumeration source vs. using the unit files as effective enumeration source is, then please think about wildcard enable lines in preset files (which are unusable as enumeration source) and the global fallback default of "enable". Anyway, I'd be open to extend the preset logic like explained above, patches very welcome, but currently this is not implemented, and the Alias= thing is the only implemented option you have. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
