From owner-freebsd-rc@FreeBSD.ORG Sun Oct 26 21:00:27 2014 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98FB92C5 for ; Sun, 26 Oct 2014 21:00:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F5AA7E9 for ; Sun, 26 Oct 2014 21:00:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9QL0RdQ085486 for ; Sun, 26 Oct 2014 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201410262100.s9QL0RdQ085486@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-rc@FreeBSD.org Subject: Problem reports for freebsd-rc@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 26 Oct 2014 21:00:27 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:00:27 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ----------------+-----------+------------------------------------------------- Patch Ready | 169047 | [rc.subr] [patch] /etc/rc.subr not checking som 1 problems total for which you should take action. From owner-freebsd-rc@FreeBSD.ORG Thu Oct 30 02:53:27 2014 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C906C91E for ; Thu, 30 Oct 2014 02:53:27 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5958F72 for ; Thu, 30 Oct 2014 02:53:26 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9U2qpaZ052770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Oct 2014 11:53:01 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.9/8.14.8) with ESMTP id s9U2qmMm061147; Thu, 30 Oct 2014 11:52:51 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 30 Oct 2014 11:33:12 +0900 (JST) Message-Id: <20141030.113312.1733136541403770348.hrs@allbsd.org> To: freebsd-lists@christianserving.org Subject: Re: [CFT] multiple instance support in rc.d script From: Hiroki Sato In-Reply-To: <685F1351-19A9-47F8-8119-AD6FAE903B10@christianserving.org> References: <20141017.102259.2303779237508789020.hrs@allbsd.org> <685F1351-19A9-47F8-8119-AD6FAE903B10@christianserving.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Oct_30_11_33_12_2014_685)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 30 Oct 2014 11:53:06 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 02:53:28 -0000 ----Security_Multipart(Thu_Oct_30_11_33_12_2014_685)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Riggs wrote in <685F1351-19A9-47F8-8119-AD6FAE903B10@christianserving.org>: fr> On 16 Oct 2014, at 20:22, Hiroki Sato 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)----