[systemd-devel] Instantiated services in presets

Vivenzio Pagliari vivenzio.pagliari at nokia.com
Thu Aug 6 03:10:29 PDT 2015


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?

Cheers,
Vivenzio


More information about the systemd-devel mailing list