[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