[systemd-devel] instantiated services set up

Jan Včelák jan.vcelak at nic.cz
Tue Aug 26 07:43:47 PDT 2014


Hello list!

I have a few questions regarding a proper way to setup and use template 
instantiated services.

We develop an authoritative DNS server called Knot DNS. Currently, we provide 
knot.service unit file to start a single instance of the server. However, some 
of our users need multiple instances running with different configuration. 
>From this reason, I wanted to add knot at .service template file to allow 
multiple instances of the server.

This is how the units look like:

knot.service:
> [Unit]
> Description=Knot DNS Server
> After=syslog.target network.target
> 
> [Service]
> ExecStart=/usr/sbin/knotd -c /etc/knot/knot.conf
> ExecReload=/usr/sbin/knotc -c /etc/knot/knot.conf reload
> 
> [Install]
> WantedBy=multi-user.target

knot at .service:
> [Unit]
> Description=Knot DNS Server (%i.conf)
> After=syslog.target network.target
> 
> [Service]
> ExecStart=/usr/sbin/knotd -c /etc/knot/%i.conf
> ExecReload=/usr/sbin/knotc -c /etc/knot/%i.conf reload
> 
> [Install]
> WantedBy=multi-user.target

And here are my questions:

1.) Is it valid to ship both knot.service and knot at .service file?

Most of the users will run a single instance of Knot DNS. Therefore I want to 
keep existing knot.service in place. In this case, specifying knot(.service) 
as an instance name in a systemctl command is more comfortable than a bit 
cryptic knot at knot(.service). Is there a better solution?

2.) Is there a way to make knot.service and knot at .service units to conflict in 
a way that if one of these is running, the other will fail to start?

I tried adding Conflicts=knot.service to Unit section of knot at .service, which 
makes the conflicting service to stop silently. That is fine, but may be 
confusing for the user. I would rather see systemctl to fail with an error 
message. Is that possible?

3.) In case of multiple instances, is there a way to control them all at once?

The idea is following:

$ systemctl enable knot at internal
$ systemctl enable knot at public
$ systemctl start <all-knot-instances>
$ systemctl reload knot at public

where <all-knot-instances> stands for something which means all instances 
without enumerating them.

One of our users suggested to create a knot.target, install the instances into 
the target and add BindsTo=knot.target into knot at .service. I think this is not 
a proper use of BindsTo and additionally, this does work for 
start/stop/restart only and doesn't work for reload.


Thanks and regards,

Jan


More information about the systemd-devel mailing list