From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QClt4-0006M4-VV for garchives@archives.gentoo.org; Thu, 21 Apr 2011 04:53:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6CC0B1C058; Thu, 21 Apr 2011 04:52:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2C53B1C021 for ; Thu, 21 Apr 2011 04:52:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 752281B4001 for ; Thu, 21 Apr 2011 04:52:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 required=5.5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8t6ynD719MC for ; Thu, 21 Apr 2011 04:52:18 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 80BC61B4044 for ; Thu, 21 Apr 2011 04:52:17 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QClsC-0001qC-ID for gentoo-dev@gentoo.org; Thu, 21 Apr 2011 06:52:12 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2011 06:52:12 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2011 06:52:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: openrc use flag Date: Thu, 21 Apr 2011 04:52:01 +0000 (UTC) Message-ID: References: <20110420172419.GC12411@linux1> <1303322561.22688.9.camel@tablet> <20110420182253.GA12829@linux1> <20110420203327.36ae5c7d@pomiocik.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.134 (Wait for Me; GIT 9383aac branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: eeef0b5155cbf00e9f2d1cbf0628d167 Micha=C5=82 G=C3=B3rny posted on Wed, 20 Apr 2011 20:33:27 +0200 as excer= pted: > On Wed, 20 Apr 2011 13:22:53 -0500 William Hubbs > wrote: >=20 >> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote: >> > =D0=92 =D0=A1=D1=80=D0=B4, 20/04/2011 =D0=B2 12:24 -0500, William Hu= bbs =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> > > The author of the bug feels that the way to fix this is for us to >> > > put a check in openrc that makes it refuse to run services if it >> > > was not used in the boot process. >> >=20 >> > This is good idea to have in any case since I remember my system wen= t >> > crazy after I've tried to start some service inside chroot. >>=20 >> My concern about it though is prefix installs. >=20 > [The attached patch] is based on the assumption that in order to run > cleanly, OpenRC needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark > all services stopped). It assumes that the basic effect of a running > OpenRC is a determined runlevel stored in ${RC_SVCDIR}/softlevel file. >=20 > I tested that approach with clean OpenRC and systemd installs, and it > doesn't create any issues. I'd appreciate if someone with Prefix system > could test it as well. > http://bugs.gentoo.org/show_bug.cgi?id=3D364159. The patch seems reasonable, but I can't but think that there's likely=20 corner-cases that may be unknown ATM that could complicate things. If we= =20 establish a slightly broader base now, it can be reasonably expanded in=20 the future. What about handling this much the same as subsystem-type auto-detection=20 was ultimately handled, but controlling how much of openrc should run: 1) Auto: (like rc_sys being commented out). This would do the auto-detec= t=20 thing using something like the suggested softlevel file detection patch. 2) On: Openrc is locked ON, and will try to handle everything. This=20 could be the default (much like rc_sys=3D""). 3) Off: Openrc is locked OFF, and will immediately terminate as soon as i= t=20 loads the config far enough to see that it is OFF, if anything attempts t= o=20 run it. 4) Later? Nodep: (Target stable-next?) If the setting is "nodep", openr= c=20 should assume all deps are met and simply run the script it is asked to=20 run, only. 5) Optionally, service.allowed: (Target bluesky?) Another setting could=20 list specific services that openrc should be allowed to run. If=20 service.allowed isn't empty/unset, anything not listed would not be run. = =20 Nodep mode would be altered slightly by this, in that any listed service=20 could be depended normally, while anything not listed would be assumed to= =20 be dependency-met. Normal (auto/on) mode would work in the reverse for=20 anything not listed. Since openrc isn't allowed to touch those services=20 but is operating in normal dependency mode, to openrc they'd not exist an= d=20 therefore block the start of any depending services as well. 6) Optionally, service.provided: To go along with #5, for openrc in norma= l=20 mode, it could borrow the "package.provided" concept from portage, making= =20 it "service.provided". For normal mode, services listed in this third=20 setting, but ONLY these services, would be assumed to be met much as if=20 openrc was operating in nodeps mode. Services not in this list would be=20 treated as above. (This would allow openrc to nodep on services in=20 service.provided, while failing OTHER deps not found in service.allowed,=20 if service.allowed isn't empty/unset. 7) Optionally, service.blacklisted. This would be the negative version o= f=20 #5. Presumably, if both service.allowed AND service.blacklisted are set=20 and non-empty, one would take precedence and the other would be ignored=20 (with documentation as to which was which). Obviously #5-7 are wish-list, not really appropriate for our current=20 target-stable. However, *if* they were thought sufficiently useful to=20 code up, these features could appear with a later version. At least #1-3 should be quite easy to code and appropriate for stable,=20 since the config concept and implementation has already been tested to=20 some degree with the current but quite new subsystem-type implementation. #4 falls in the middle. I threw it in based on jer's suggestion, which=20 I'd like to see even if #5-7 aren't implemented, but it's a big enough=20 feature-add that it really should have additional testing. As such I don'= t=20 see it for current-stable-target, but perhaps stable-next? --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman