[systemd-devel] Instantiated services in presets

[Vivenzio Pagliari]

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?

cheers,
Vivenzio