[systemd-devel] instantiated services set up

[Lennart Poettering]

On Tue, 26.08.14 16:43, Jan Včelák (jan.vcelak at nic.cz) wrote:

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

After=syslog.target is redundant since a long time. Consider removing
this. And After=network.target usually doesn't do what one might thing
it does and with well written software that listens to rtnl or uses
IP_FREEBIND not even necessary...

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

Sure, but for the sake of simplicity and not confusing the user I would
avoid this.

I'd just ship the templated version, and then maybe add
DefaultInstance=something to the [Install] section in order to make one
instance the "default" one...

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

Well, with DefaultInstance=default or so knot at default.service could be
your implied default if people just invoke "systemctl enable knot at .service"...

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

Hmm, we currently don't support any dependency type like this. And I am
very conservative about adding new dep types, unless we have a very
strong reason for it...

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

Use PartOf= for this...

Lennart

-- 
Lennart Poettering, Red Hat