[systemd-devel] Instantiated services in presets

[Lennart Poettering]

On Thu, 06.08.15 13:22, Vivenzio Pagliari (vivenzio.pagliari at nokia.com) wrote:

> On 2015-08-06 12:21:33, ext Lennart Poettering wrote:
> > On Thu, 06.08.15 12:10, Vivenzio Pagliari (vivenzio.pagliari at 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 at x      works not     works      differing behaviour
> > > 
> > > 
> > >  Footnotes:
> > >  * DefaultIntance is defined in X at .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 at .service you could add this to it:
> > 
> > [Install]
> > Alias=multi-user.target.wants/my-little-getty at foo.service multi-user.target.wants/my-little-getty at 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?

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 foo at bar.service" 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 foo at .service bar waldo quux

This would mean that if "preset-all" is done, and foo at .service 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