В Tue, 26 Aug 2014 16:43:47 +0200 Jan Včelák <jan.vce...@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@.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@.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@.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@knot(.service). Is there a better solution? > > 2.) Is there a way to make knot.service and knot@.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@instance.service, but would need to do it for each instance). > I tried adding Conflicts=knot.service to Unit section of knot@.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@internal > $ systemctl enable knot@public > $ systemctl start <all-knot-instances> Not that I know of (in this form that is). > $ systemctl reload knot@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@.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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
