[systemd-devel] Instantiated services in presets

[Lennart Poettering]

On Thu, 06.08.15 12:10, Vivenzio Pagliari (vivenzio.pagliari at nokia.com) 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 X at .service 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 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.
> 
> 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
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...

Lennart

-- 
Lennart Poettering, Red Hat