[systemd-devel] systemd and templates

Michal Sekletar msekleta at redhat.com
Mon Jun 25 00:43:11 PDT 2012


Hello everyone out there,

We would like to start a discussion about a way how should systemd deal
with template units, because we consider current state as not sufficient
to meet all use cases very often seen in server administration.

Consider a scenario where administrator has a lot of instances of some
daemon running, e.g vsftpd. We have templates in systemd, but there is
no way[1] how to enable/disable them. So administrator has to do it by
hand which is cumbersome, error prone and time consuming considering the
fact that such an administrative task is fairly often done by
administrators and we should have means, such that administrators can do
it using systemctl interface. Otherwise one can argue that templates in
systemd are only partly usable, which is certainly true today.  Having
said that, it is clear that we need to add a support for
enabling/disabling template units. Reason, why they exist in a first
place, is a need for more than one instance of a daemon running, so we
have to provide a standard, both well implemented and documented way how
to use templates properly. Hereby follows proposal on enabling/disabling
templates, also a need for a new dependency type is implied.

Desired result: 
#systemctl enable openvpn at work.service 
ln -s /usr/lib/systemd/system/openvpn at .service \
      /usr/lib/systemd/system/multi-user.target.wants/openvpn at work.service

Also it should be possible to group more instances together
and control them as a group. In such case template service will
contain WantedBy= option, where some other target should be specified,
e.g. opevpn.target.  However, instances should start/stop whenever the
target is started/stopped. Therefore we need to configure some type of
dependency between template and target in [Unit] section. Currently we
don't have a dependency type which is suitable for this scenario. We
could use Requires or BindTo, and it will work in case where, one will
stop target and all associated instances will be stopped as well,
but on the other hand starting one instance will pull in target and
all instances. To be able to handle such a scenario it is necessary
to add new dependency type. Semantic should be similar to Upstart's
"stop on stopped" job configuration option.

Another feature which systemd currently doesn't support and it's
closely related to previous issues, is starting instances based on
configuration. There should be an option to enable a behavior, when
instances of template are created and started automatically based on
configuration files for a particular deamon and controlled via common
target as described above.

We would like to thank you in advance for any insightful feedback and
suggestions on this matter.

[1] It is possible to use Alias= in [Install] section of template, but
we consider this as a workaround rather than solution.

--
Lukas Nykryn and Michal Sekletar 
Red Hat, BaseOS Engineering, Brno Czech Republic



More information about the systemd-devel mailing list