[systemd-devel] instantiated services set up

[Andrei Borzenkov]

В Tue, 26 Aug 2014 16:43:47 +0200
Jan Včelák <jan.vcelak at nic.cz> пишет:

> 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
> > 

As was discussed just couple of days ago, if your instance name is
actually a file name, you should use %f and properly escape instance
name (if required).

> > [Install]
> > WantedBy=multi-user.target
> 
> And here are my questions:
> 
> 1.) Is it valid to ship both knot.service and knot at .service file?
> 

Yes. They are not really related in any way.

> 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 actually thought it had been implemented, but I cannot find how to do
it either.

On a side note, Conflict in other direction is impossible to express
(you can say Conflicts=knot at instance.service, but would need to do it
for each instance).

> 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>

Not that I know of (in this form that is).

> $ 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.
> 

That's what PartOf is for. Make it PartOf=knot.target.