Date: Thu, 30 Oct 2014 11:33:12 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: freebsd-lists@christianserving.org Cc: freebsd-rc@freebsd.org Subject: Re: [CFT] multiple instance support in rc.d script Message-ID: <20141030.113312.1733136541403770348.hrs@allbsd.org> In-Reply-To: <685F1351-19A9-47F8-8119-AD6FAE903B10@christianserving.org> References: <20141017.102259.2303779237508789020.hrs@allbsd.org> <685F1351-19A9-47F8-8119-AD6FAE903B10@christianserving.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Thu_Oct_30_11_33_12_2014_685)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Riggs <freebsd-lists@christianserving.org> wrote in <685F1351-19A9-47F8-8119-AD6FAE903B10@christianserving.org>: fr> On 16 Oct 2014, at 20:22, Hiroki Sato <hrs@FreeBSD.org> wrote: fr> fr> > I would like your feedback and testers of the attached patch. This fr> > implements multiple instance support in rc.d scripts. You can try it fr> > by replacing /etc/rc.subr with the attached one. fr> fr> fr> I really like the idea, as I have written at least 2 or 3 ports in fr> which I have needed support for multiple "profiles" (as I have seen fr> them called in several ports). So, I had to duplicate the fr> multiple-instance logic in the rc script for each. This would save all fr> of that aggravation. fr> fr> The only concern I have with generalizing the approach in rc.subr, fr> though, is that not every app/daemon/script can or should support fr> it. I worry that some things if run multiple times may stomp on each fr> other or corrupt data or break something. It seems that there should fr> be a way for each rc script to either opt in or opt out of multiple fr> instance support. I don't know which is better. Opt-in is probably fr> safer, but then core devs and port maintainers have to make specific fr> changes to support it. :-\ A daemon never runs multiple times unless different configurations are added for each explicitly. It just tries to run rc.d/foo multiple times with different variable configurations which are manually set. The default values are set to the same as ones for a single instance, so if foo_instances is set to "one two" and there is no explicit variable configuration for the second instance, the first instance runs but the second always fails because of PID check. To run multiple instances, different command, procname, or pidfile must be defined. I do not think this can lead to unexpected data corruption or needs an additional opt-in knob in individual rc.d scripts. This is already opt-in feature since a specific configuration is always required to enable it. Each instance can run in different jails from the host environment or chroot jails, for complex example. So we should not assume whether multiple instance support is useless for a specific daemon or not and allow/disallow it on the rc.d script's side. This just provides a tool for advanced users, not a policy. Of course, a port maintainer can still leverage this framework to implement multiple "profiles" by overriding foo_instances variable, maybe with a warning message that explains the user-configured one is ignored, and setting appropriate default values for each instance. -- Hiroki ----Security_Multipart(Thu_Oct_30_11_33_12_2014_685)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlRRo2gACgkQTyzT2CeTzy0cvgCeJWCOSyfm3tDoE1SPmk2bReKV cjMAnjtm7BzC1r0ciJAtl2nTTRBsjO8a =rHg1 -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Oct_30_11_33_12_2014_685)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141030.113312.1733136541403770348.hrs>