On Tue, 26.08.14 16:43, Jan Včelák ([email protected]) 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 > > [email protected]: > > [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 [email protected] 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@knot(.service). Is there a better solution? Well, with DefaultInstance=default or so [email protected] could be your implied default if people just invoke "systemctl enable [email protected]"... > 2.) Is there a way to make knot.service and [email protected] 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 [email protected], 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@internal > $ systemctl enable knot@public > $ systemctl start <all-knot-instances> > $ 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 [email protected]. 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
