Re: [systemd-devel] instantiated services set up
On Tue, 04.11.14 21:42, Tomasz Torcz (to...@pipebreaker.pl) wrote: > On Tue, Nov 04, 2014 at 08:56:48PM +0100, Jan Včelák wrote: > > Hi! > > > > > > OK. I will remove the syslog. But I will have to keep network.target for > > > > now as we support non-Linux systems as well. Adding support for rtnl or > > > > IP_FREEBIND would mean duplicating a lot of code... probably. > > > > > > Note that invoking IP_FREEBIND is just a single setsockopt() line... > > > > You are right. We enabled IP_FREEBIND after all. (And we also added > > IP_BINDANY > > and IPV6_BINDANY on FreeBSD to achieve the same behavior.) > > > > On the other hand, we cannot give the administrator proper feedback when > > the > > daemon is configured incorrectly. > > > > If you need, you can first try binding without IP_FREEBIND. If it fails, > you can print "Configured address (xxx) not available yet", enable IP_FREEBIND > and call bind() again. I'd recommend this, too. I'd check for the right errno first though, given that there might be other reasons why bind() could fail, and one shouldn't confuse the user with misleadin error messages. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
On Tue, Nov 04, 2014 at 08:56:48PM +0100, Jan Včelák wrote: > Hi! > > > > OK. I will remove the syslog. But I will have to keep network.target for > > > now as we support non-Linux systems as well. Adding support for rtnl or > > > IP_FREEBIND would mean duplicating a lot of code... probably. > > > > Note that invoking IP_FREEBIND is just a single setsockopt() line... > > You are right. We enabled IP_FREEBIND after all. (And we also added > IP_BINDANY > and IPV6_BINDANY on FreeBSD to achieve the same behavior.) > > On the other hand, we cannot give the administrator proper feedback when the > daemon is configured incorrectly. > If you need, you can first try binding without IP_FREEBIND. If it fails, you can print "Configured address (xxx) not available yet", enable IP_FREEBIND and call bind() again. -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
Hi! > > OK. I will remove the syslog. But I will have to keep network.target for > > now as we support non-Linux systems as well. Adding support for rtnl or > > IP_FREEBIND would mean duplicating a lot of code... probably. > > Note that invoking IP_FREEBIND is just a single setsockopt() line... You are right. We enabled IP_FREEBIND after all. (And we also added IP_BINDANY and IPV6_BINDANY on FreeBSD to achieve the same behavior.) On the other hand, we cannot give the administrator proper feedback when the daemon is configured incorrectly. > > DefaultInstance sounds great. Will this get backported into systemd-stable > > at some time? Because I'm looking for a solution for RHEL 7. > > Please file a bug for RHEL 7 and the right peple will make sure this > happens. OK. I will do that. Thanks a lot. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
On Mon, 15.09.14 13:03, Jan Včelák (jan.vce...@nic.cz) wrote: > > 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... > > OK. I will remove the syslog. But I will have to keep network.target for now > as we support non-Linux systems as well. Adding support for rtnl or > IP_FREEBIND would mean duplicating a lot of code... probably. Note that invoking IP_FREEBIND is just a single setsockopt() line... > > > 1.) Is it valid to ship both knot.service and knot@.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... > > DefaultInstance sounds great. Will this get backported into systemd-stable at > some time? Because I'm looking for a solution for RHEL 7. Please file a bug for RHEL 7 and the right peple will make sure this happens. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
On Tue, Sep 16, 2014 at 01:22:39PM +0200, Jan Včelák wrote: > Hi Colin, > > > This approach gives you nice flexibility and control over instance > > units, but still gives you the ability to start/stop individual > > instances and control all of them at once too! > > Yes, you are right. I tried this and it works pretty well. > > However, the knot.target can be used only for start, stop, and restart. It > cannot be used for reload... :-( ReloadPropagatedFrom=/ReloadPropagatedTo= ? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
Hi Colin, > This approach gives you nice flexibility and control over instance > units, but still gives you the ability to start/stop individual > instances and control all of them at once too! Yes, you are right. I tried this and it works pretty well. However, the knot.target can be used only for start, stop, and restart. It cannot be used for reload... :-( Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
Jan Včelák wrote on 15/09/14 12:03: >>> > > 3.) In case of multiple instances, is there a way to control them all at >>> > > once? >>> > > >> > >> > Use PartOf= for this... > OK. Thanks. I will take a look at it! Just for a few more hints here: You would create a knot.target unit which is just a standard target unit, with a name and not much else, but it *would* have it's own [Install] section with "WantedBy=multi-user.target" In the knot@.service you would add: PartOf=knot.target and you would *replace* the WantedBy=multi-user.target with WantedBy=knot.target. This way, you can "systemctl enable knot@.service" and the default instance will be enabled. But in this context, enabling it just means it will start whenever knot.target starts, not multi-user.target. THis means an admin can easily disable all instances of knot@.service simply by doing: "systemctl disable knot.target" This approach gives you nice flexibility and control over instance units, but still gives you the ability to start/stop individual instances and control all of them at once too! HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
> 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... OK. I will remove the syslog. But I will have to keep network.target for now as we support non-Linux systems as well. Adding support for rtnl or IP_FREEBIND would mean duplicating a lot of code... probably. > > 1.) Is it valid to ship both knot.service and knot@.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... DefaultInstance sounds great. Will this get backported into systemd-stable at some time? Because I'm looking for a solution for RHEL 7. > > 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 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? > > 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... Fine. This is not that important. > > 3.) In case of multiple instances, is there a way to control them all at > > once? > > > > Use PartOf= for this... OK. Thanks. I will take a look at it! Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
On Tue, 26.08.14 16:43, Jan Včelák (jan.vce...@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@.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@.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@knot(.service). Is there a better solution? Well, with DefaultInstance=default or so knot@default.service could be your implied default if people just invoke "systemctl enable knot@.service"... > 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 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? 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 > $ systemctl reload knot@public > > where 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. Use PartOf= for this... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
В Tue, 26 Aug 2014 16:43:47 +0200 Jan Včelák пишет: > 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 Not that I know of (in this form that is). > $ systemctl reload knot@public > > where 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
[systemd-devel] instantiated services set up
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 > > [Install] > WantedBy=multi-user.target And here are my questions: 1.) Is it valid to ship both knot.service and knot@.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@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 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 $ systemctl reload knot@public where 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. Thanks and regards, Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
