Re: [systemd-devel] How to properly write an umbrella unit
Lennart Poettering wrote: Daurnimator wrote: Lennart Poettering wrote: Maybe we can change the manager core to propagate Reload() calls for unit type that do not support it natively to other units listed in PropagateReloadsTo= and then become a NOP. Or in other words: invoking reload on a target that knows no PropagateReloadsTo= should continue to return an error. But if such deps are defined, it should become a silent NOP and propagate the event. Could you file an RFP issue on github asking for this? [or even better, send a PR with a patch... ;-) ] ReloadPropagatedFrom= would seem to be more useful here. Well, ReloadPropagateFrom= is the inverse of PropagateReloadsTo=. If there is a dep of the first kind from A to B, there's always a dep of the second kind from B to A, and vice versa. Why should reloading a target error in the first place? == why not just a NOP? Hides bugs? reloading a target makes no sense, unless you use it for reload propagation. But stopping and restarting a target already makes sense if you use PartOf=foo.target. Unfortunately one cannot specify ConsistsOf in a unit file, which is a really annoying limitation. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: Unfortunately one cannot specify ConsistsOf in a unit file, which is a really annoying limitation. That limitation exists for a reason: systemd loads unit files lazily: only units that are referenced by some other unit are loaded. Thus, just sticking a unit file somewhere, and writing ConsistsOf= into it, would generally not work, since the dep would never be considered unless you also have a dep from something else on it. To avoid this confusion we simply don't support it at all. (Only way to make this work would be by allowing ConsistsOf= deps via .consistsof subdirs with symlinks like we support it for .wants, and then have ConsistsOf= in the [Install] section, if you follow what I mean). 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] How to properly write an umbrella unit
Lennart Poettering wrote: On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: Unfortunately one cannot specify ConsistsOf in a unit file, which is a really annoying limitation. That limitation exists for a reason: systemd loads unit files lazily: only units that are referenced by some other unit are loaded. By reference you mean a reference that causes a unit file to be loaded like Wants? I understand that ConsistsOf is not (would not be) such a reference, but TBH I don't quite understand why. Is this something to do with positive and inverse dependencies and PartOf being already a positive one? (I'm staring at the UnitDependency enum). I kinda understand it was made this way mainly or even only with instance units in mind. Correct? Thus, just sticking a unit file somewhere, and writing ConsistsOf= into it, would generally not work, since the dep would never be considered unless you also have a dep from something else on it. To avoid this confusion we simply don't support it at all. What I've actually tried after learning about PartOf some time ago: # foo.target [Unit] Wants=a.service b.service c.service ConsistsOf=a.service b.service c.service so I can start/stop/restart a bunch of services with systemctl. Both lists in one place, so it would be hard to forget about something while making changes. Single file to edit - neat. Just perfect - that's what I thought until a moment later. (Only way to make this work would be by allowing ConsistsOf= deps via .consistsof subdirs with symlinks like we support it for .wants, and then have ConsistsOf= in the [Install] section, if you follow what I mean). .consistsof and [Install]/PartOf would sound reasonable, just like .wants and [Install]/WantedBy. [Install]/ConsistsOf seems wrong. But how will this solve anything? Is .wants different from Wants? -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
2015-07-22 19:15 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Tue, 21.07.15 13:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
Can I write my nifty.target as a service? I have seen in this case
nifty.service files with Exec=/bin/true to basically create a no-op
service, but that's ugly.
That's a hack. A target is for grouping things, they basically are
services without processes attached to them. You really should use
targets for this, and not misuse services.
Afaik, there is no way to have a .target reloaded and that reload
request propagated to all services in that target.
Say you have foo.target consisting of bar.service and baz.service,
how can you achieve that
systemctl reload foo.target propagates that reload request to {bar,baz}.service?
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, 21.07.15 13:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target Unrelated to the actual topic of this thread: this line above usually doesn't do what people assume it does: It does not start the daemon after the network is up -- which is what most folks might think --, that's what network-online.target is for. Also, most daemons actually don't need the network to be up, and it is bad style to make daemons wait for external events such as DHCP events anyway. Hence, don't use this. The primary effect of ordering something after network.target is actually at shut down, since it ensures that the service is stopped before the network is turned off.) It is usually a good to remove such lines, unless you really really know you need it. In this case the target should definitely not list this, if at all the services should, but probably not even they. This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Going for a target for this sounds like the right choice, and if your distro cannot support that nicely, it really should be improved to support it. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. That's a hack. A target is for grouping things, they basically are services without processes attached to them. You really should use targets for this, and not misuse services. If I move my service to a nifty@.service, how would I start two instances from a single shell command? You can also group instances with a target unit nicely. But the way to group things is via target units, nothing else. How would one handle this situation in the clear, recommended way? The way you already did it! 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] How to properly write an umbrella unit
On Wed, 22.07.15 20:28, Michael Biebl (mbi...@gmail.com) wrote:
2015-07-22 19:15 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Tue, 21.07.15 13:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
Can I write my nifty.target as a service? I have seen in this case
nifty.service files with Exec=/bin/true to basically create a no-op
service, but that's ugly.
That's a hack. A target is for grouping things, they basically are
services without processes attached to them. You really should use
targets for this, and not misuse services.
Afaik, there is no way to have a .target reloaded and that reload
request propagated to all services in that target.
Say you have foo.target consisting of bar.service and baz.service,
how can you achieve that
systemctl reload foo.target propagates that reload request to
{bar,baz}.service?
You cannot do that right now, and I am not sure you should be able to,
after all the operation does not really apply to target units.
I do see your usecase though...
Humm...
Maybe we can change the manager core to propagate Reload() calls
for unit type that do not support it natively to other units listed in
PropagateReloadsTo= and then become a NOP.
Or in other words: invoking reload on a target that knows no
PropagateReloadsTo= should continue to return an error. But if such
deps are defined, it should become a silent NOP and propagate the
event.
Could you file an RFP issue on github asking for this? [or even better,
send a PR with a patch... ;-) ]
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] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 09:42:38PM +0200, Michael Biebl wrote: Have a look at the openvpn package in Debian. It implements something like you have in mind. There are multiple openvpn@.service instances and a single openvpn.service which can be used by the admin to start/stop/restart them. That uses a generator, which is somewhat oversized for the question at hand. And it's a service with ExecStart=/bin/true which is a hackish workaround. But if that's the way to go, I'm fine with it. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Thu, 23.07.15 10:41, Daurnimator (q...@daurnimator.com) wrote: On 23 July 2015 at 04:41, Lennart Poettering lenn...@poettering.net wrote: Maybe we can change the manager core to propagate Reload() calls for unit type that do not support it natively to other units listed in PropagateReloadsTo= and then become a NOP. Or in other words: invoking reload on a target that knows no PropagateReloadsTo= should continue to return an error. But if such deps are defined, it should become a silent NOP and propagate the event. Could you file an RFP issue on github asking for this? [or even better, send a PR with a patch... ;-) ] ReloadPropagatedFrom= would seem to be more useful here. Well, ReloadPropagateFrom= is the inverse of PropagateReloadsTo=. If there is a dep of the first kind from A to B, there's always a dep of the second kind from B to A, and vice versa. Why should reloading a target error in the first place? == why not just a NOP? Hides bugs? reloading a target makes no sense, unless you use it for reload propagation. Hence we should generate an error. 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] How to properly write an umbrella unit
On 23 July 2015 at 04:41, Lennart Poettering lenn...@poettering.net wrote: Maybe we can change the manager core to propagate Reload() calls for unit type that do not support it natively to other units listed in PropagateReloadsTo= and then become a NOP. Or in other words: invoking reload on a target that knows no PropagateReloadsTo= should continue to return an error. But if such deps are defined, it should become a silent NOP and propagate the event. Could you file an RFP issue on github asking for this? [or even better, send a PR with a patch... ;-) ] ReloadPropagatedFrom= would seem to be more useful here. Why should reloading a target error in the first place? == why not just a NOP? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Have a look at the openvpn package in Debian. It implements something like you have in mind. There are multiple openvpn@.service instances and a single openvpn.service which can be used by the admin to start/stop/restart them. 2015-07-21 13:43 GMT+02:00 Marc Haber mh+systemd-de...@zugschlus.de: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. If I move my service to a nifty@.service, how would I start two instances from a single shell command? How would one handle this situation in the clear, recommended way? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 02:20:39PM +0100, Dimitri John Ledkov wrote: And then people can do e.g.: systemctl enable nifty@4.service nifty@6.service systemctl start nifty@*.service systemctl stop nifty@*.service As I mentioned in my original mail, this is explictly not wanted, as most users will have to start and stop both instances together. We cannot make our lives simpler at the cost of our users. And yes, this is true for both systemd upstream and software packagers, a transitive relationship. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to properly write an umbrella unit
Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. If I move my service to a nifty@.service, how would I start two instances from a single shell command? How would one handle this situation in the clear, recommended way? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit : This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Hi, Package-provided targets works well, but by default debhelper will try to enable everything. You'd need to overide dh_systemd_enable dh_systemd_start: https://sources.debian.net/src/systemd-cron/1.5.2-1/debian/rules/ | override_dh_systemd_enable: | # Only enable cron.target, it pulls in all the others via .timer files. | dh_systemd_enable cron.target | | override_dh_systemd_start: | # Only start cron.target, it pulls in all the others via .timer files. | dh_systemd_start cron.target Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. PostgreSQL does that for some reason: https://sources.debian.net/src/postgresql-common/169/systemd/postgresql.service/ How would one handle this situation in the clear, recommended way? Can't help for this. Greets, Alexandre ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 01:40:31PM +0100, Colin Guthrie wrote: In this case, I'd perhaps recommend NOT including [Install] sections fir your two .service files and instead make your make install action write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus the user could never disable the individual components of your daemon themselves and thus not need to rely on distro scripts to create them at install time. No, I'd like to give the local admin an option to disable parts of course. My work is about choice and robustness. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Hi Alexandre, thanks for your fast answer and correctly guessing my Distribution ,-) On Tue, Jul 21, 2015 at 02:13:12PM +0200, Alexandre Detiste wrote: Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit : This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Hi, Package-provided targets works well, but by default debhelper will try to enable everything. In my case, dh_systemd_enable doesn't install the file: dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v6.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v4.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v4-old.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postrm.debhelper.new sed s/#UNITFILES#/isc-dhcp-server-v6.service isc-dhcp-server-v4.service isc-dhcp-server-v4-old.service/ /usr/share/debhelper/autoscripts/postrm-systemd debian/isc-dhcp-server.postrm.debhelper.new echo '# End automatically added section' debian/isc-dhcp-server.postrm.debhelper.new cat debian/isc-dhcp-server.postrm.debhelper debian/isc-dhcp-server.postrm.debhelper.new mv debian/isc-dhcp-server.postrm.debhelper.new debian/isc-dhcp-server.postrm.debhelper (grep -s -v misc:Depends debian/isc-dhcp-server.substvars; echo misc:Depends=debconf (= 0.5) | debconf-2.0, init-system-helpers (= 1.18~)) debian/isc-dhcp-server.substvars.new mv debian/isc-dhcp-server.substvars.new debian/isc-dhcp-server.substvars dh_installinit -Nisc-dhcp-server install -d debian/isc-dhcp-relay/etc/init.d install -p -m755 debian/isc-dhcp-relay.init.d debian/isc-dhcp-relay/etc/init.d/isc-dhcp-relay echo # Automatically added by dh_installinit debian/isc-dhcp-relay.postinst.debhelper sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/postinst-init debian/isc-dhcp-relay.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-relay.postinst.debhelper echo # Automatically added by dh_installinit debian/isc-dhcp-relay.prerm.debhelper sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/prerm-init debian/isc-dhcp-relay.prerm.debhelper echo '# End automatically added section' debian/isc-dhcp-relay.prerm.debhelper echo # Automatically added by dh_installinit debian/isc-dhcp-relay.postrm.debhelper.new sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/postrm-init debian/isc-dhcp-relay.postrm.debhelper.new echo '# End automatically added section' debian/isc-dhcp-relay.postrm.debhelper.new cat debian/isc-dhcp-relay.postrm.debhelper debian/isc-dhcp-relay.postrm.debhelper.new mv debian/isc-dhcp-relay.postrm.debhelper.new debian/isc-dhcp-relay.postrm.debhelper dh_installinit -pisc-dhcp-server --error-handler=true #dh_systemd_start isc-dhcp-server.target and dh_systemd_enable's code specialcasing service, socket, and tmpfile, but not target, gave me the impression that target files are unsupported. My debian/rules is: override_dh_installinit: dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4 dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4-old dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v6 dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target dh_installinit -Nisc-dhcp-server dh_installinit -pisc-dhcp-server --error-handler=true what is wrong here? (if this is off-topic in systemd-devel, which I suspect, please feel free to reply in private mail instead). Greetings Marc -- - Marc Haber | I don't trust Computers. They |
Re: [systemd-devel] How to properly write an umbrella unit
Marc Haber wrote on 21/07/15 12:43: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. In this case, I'd perhaps recommend NOT including [Install] sections fir your two .service files and instead make your make install action write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus the user could never disable the individual components of your daemon themselves and thus not need to rely on distro scripts to create them at install time. Your package install script would still have to enable (or preset) the nifty.target however. This might or might not be desirable overall (in the example above, I can imagine someone still wanting to disable only the IPv6 component for example!). Col -- Colin Guthrie colin(at)mageia.org 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] How to properly write an umbrella unit
Heya, On 21 July 2015 at 12:43, Marc Haber mh+systemd-de...@zugschlus.de wrote: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: Imho targets are ugly =) I'd do a nifty@.service with: ExecStart= -%I -cf /etc/nifty/niftyd%I.conf And then people can do e.g.: systemctl enable nifty@4.service nifty@6.service systemctl start nifty@*.service systemctl stop nifty@*.service And the install section would have e.g. default instance name 4, and wanted by multi-user target. And such service should be trivial to integrate into any maintainer scripts. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
