From owner-freebsd-hackers@freebsd.org Sun Feb 10 04:37:46 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82D0114DD633 for ; Sun, 10 Feb 2019 04:37:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB51793E59; Sun, 10 Feb 2019 04:37:44 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id sgs8gfPCh8uQmsgs9ggF1f; Sat, 09 Feb 2019 21:37:42 -0700 X-Authority-Analysis: v=2.3 cv=XKpOtjpE c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=CFTnQlWoA9kA:10 a=iKhvJSA4AAAA:8 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=Y-crQ47C8yu-7etmwW0A:9 a=QiqY-oLw1HtdTI3u:21 a=alVihR9IOLASVxuU:21 a=CjuIK1q_8ugA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 3BB62127F; Sat, 9 Feb 2019 20:37:39 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x1A4bcbo042489; Sat, 9 Feb 2019 20:37:38 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x1A4bcGK042486; Sat, 9 Feb 2019 20:37:38 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201902100437.x1A4bcGK042486@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Rodney W. Grimes" cc: Cy Schubert , cem@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: nosh init system In-Reply-To: Message from "Rodney W. Grimes" of "Sat, 09 Feb 2019 20:20:28 -0800." <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Feb 2019 20:37:38 -0800 X-CMAE-Envelope: MS4wfNo9OaCHk0Nt+gWKEcxepfEFaC2oE82WFNF6SFl7y2yEkXdyUhcnxdCu5mb7q6vpPrc5VGRKGjEXtI3H16B9+GK2x3trysny104OrcEJp6cBNiR17qSo nDvNkSpa6Kx9iBWPE7nIDQgfsfK3FHYSF6W/5mzTwAcldbd8P8o9GTeho7CAod7hHnJNeWd23+dnX4zec+vvnXllQtnFXLpAeuaqUGQ85TJFPkaNkkRszpvs ZaY/JLnkmY9ENmd3qMbNi8DbnSLm5NjrMcmjMHgQIXg= X-Rspamd-Queue-Id: CB51793E59 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.67 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.91)[-0.905,0]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(-2.05)[ip: (-5.68), ipnet: 64.59.128.0/20(-2.53), asn: 6327(-1.97), country: CA(-0.09)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 04:37:46 -0000 In message <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > In message > il.com> > > , Conrad Meyer writes: > > > Hi Cy, > > > > > > On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert wr > ote: > > > > I don't see what's so "incredibly fragile" about rc(8). That's not to > > > > say there aren't better solutions, like SMF. > > > > > > Maybe "incredibly" as a choice of adjective is inappropriate. I think > > > we (you, me, and ngie@) can all agree it is somewhat fragile, and > > > there are things SMF/systemd/nosh get right that rc(8) does not > > > (today). Anyway, your next paragraph goes on to be a good start at > > > describing some of rc's fragility. :-) > > > > > > > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc > > > > script could fail hosing the boot or worse hosing the system*. Where a > > > > solution like SMF solves the problem is that should a service which > > > > other services depend on fail, only that branch of the startup tree > > > > would fail. > > > > > > Right; that's a great example. > > > > > > > In that scenario, if a service fails but sshd start, a > > > > sysadmin would still be able to login remotely to resolve the problem. > > > > So in this regard rc(8) is at a disadvantage. > > > > > > > > We could address the above paragraph by starting sshd earlier during > > > > boot thereby allowing the opportunity to fix remotely. > > > > > > I don't think that is really sufficient without substantially > > > modifying init+rc to be closer to something like systemd or SMF, > > > anyway. And then we'd rather just have something like SMF :-). > > > > I'd rather see SMF but a number felt a CDDL licensed init was > > unacceptable -- except for the fact that SMF doesn't replace init. > > > > > > > > As soon as *any* rc service fails to start (signal, non-zero exit, > > > stop_boot), rc(8) exits non-zero, causing init(8) to go to single > > > user. All service state is thrown away with rc(8) exit, but any rc.d > > > "services" that managed to start before boot failed are not > > > terminated. Even if an admin manages to log in and fix the > > > configuration, re-starting rc(8) restarts the runcom process from > > > scratch, as if nothing had already been done, without first stopping > > > anything that was already running. The only safe, reproducible way to > > > re-start rc(8) is to fully reboot the system. > > It -should- be safe to restart rc, as rc scripts should check to > see if the item they are being requested to start is already running, > rc scripts that fail to have this check are defective and should be > fixed. You should be able to invate /etc/rc.d/foo start as many > times as you want in a row and only get 1 instance of foo, with the > other starts returning "foo already running" Same with stop. > > > > > It wasn't that way 10-15 years ago. It's evolved to become this. Even > > if we stay with rc(8), quickly cobbling together a patch isn't going to > > fix it long term. Whether we use another init, an add-on like SMF, or > > make rc(8) more robust, it will not be fixed by a simple tweak here or > > there. > > Much gets broken in the name of new features sadly. That was my point. Tunnel vision. > > > > > > > > > E.g., the major pain point we run into repeatedly with restarted boot > > > is that cleanvar / cleartmp run again. This breaks ld-elf.so.hints > > > cache (anything linking /usr/local libraries ??? hope your admin is > > > running base sshd and not openssh-portable!) as well as wiping out > > > /var/run pid files (breaking "already running?" rc pid checks). As a > > > result, services get double-started. > > > > > > Cleanvar could maybe be improved to avoid this problem ??? e.g., we > > > could coordinate with the kernel to set a per-boot, persisted flag > > > that cleanvar has completed, even if rc(8) exits ??? but the broad class > > > of problems would remain (rc.d autostart is stateful, but any partial > > > failure destroys all state). > > > > This needs more than improving cleanvar or some other script. It's like > > whack-a-mole. (The rest of this not specifically talking to you > > Conrad.) This is why every one to two months this topic comes up again > > and again and again. It's a pain point. (And also the shiny new object > > syndrome.) Various people suggest their favourite init(8) replacement > > and the bikeshed starts up again. > > Shiny new things also come with shiny new problems, I would actually > often rather repair a broken old something than get a new shiny > something as I know the defects of the raty old something. Agreed. Like building on a foundation of sand. > > > To avoid bikeshedding this to death again, we enumerated two issues so > > far. Let's continue to list issues. I also think that this should be a > > BSDCan devsummit whiteboard topic where we list issues in one column > > and next to it we list possible solutions, after listing all the issues > > first. And finally if this is too large for one person to work on, > > assign the various issues to willing developers. > > We do not need to wait for BSDCan, there are more of us here on this > list than at any dev summit. True but whiteboards help. My point is let's itemize a list of issues first. Write down (figuratively speaking) all ideas to address the listed issues. Select the best ideas. Implement them. > > > > > One final thought. init(8) and rc(8) requirements for desktop/laptop, > > server, embedded, and mobile are probably different enough that their > > requirements may compete with each other. Some embedded applications > > may desire a simple rc(8) whereas server or desktop a heavier weight > > solution. > > It is rather simple to just drop the whole rc.d and rewrite > /etc/rc for the embeded situtaion, going back to the 4.3 era. > > Though we might want to go over to the rc mailling list? Excellent idea! -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.