[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