From owner-freebsd-hackers@freebsd.org Sun Feb 10 20:51:05 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 C82A614DB3F8 for ; Sun, 10 Feb 2019 20:51:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED44A6A11F for ; Sun, 10 Feb 2019 20:51:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id y4so10010792qtc.10 for ; Sun, 10 Feb 2019 12:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q4pFiPh74T8ODK+U8YYN6/2uaKfJbSvXMSa5S8d7SpM=; b=cz3SKcwNCWotp2lLtK/VCPEL51GzytYWyqw4y72zVGiaODkq15m3ExPgs8Yaz0+Iqs o8PkY40uTnzum+15tELJD+hGnMiM1coI7jL0cWAV7Y7IW3XE1A/ywip34uh8Jmk/AozU T7ydJuHIRkZUOA7AKBtI60B3JIjg3nvrnIxta033/FuVKio3nMmRGH45PlSr+OLqmbQS /GJGvjIPmAAAJ4tEo/f0htq1D4QO9CkeoYVXYxRMttVnZlkcTMhT733EA8+uLiJVhoKN WEewpALROwfwCvp5oaPy7PTCamWz+EwO+3t/yuk/795pKXjQn+JgFVz/RnVVVKCRly/6 xiQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q4pFiPh74T8ODK+U8YYN6/2uaKfJbSvXMSa5S8d7SpM=; b=U0ZpMgNq8sC82QTFbhu7R5MI8Xc+iLkbLNUH+lU0PuZZvCx095SLpbdBzdzdmyI8Hv S/e05Sy0DYCMmukAodeqZKkbLZLszdQ3CZzho9w8HhcaIBufWcAFB+1QlCVZSD4/+6L7 qBA9jhSKDtrIVGijgOOxWcRcWdwd86Rd7kiz8+E3HA18NjNOYxZizxgSe6aM+FD3/1Oo RE1XWLWSR6Qhj9Y19jpQUmzWDHbk25cPmPKF9e3NZ1mYqAXPUqh9x73uaEsM0mexm9hn /h+6eSZBumjXRd+noXvfXEp0uIEneUNASh32qxUk6eWbr17VQ87XnK7OFnic7yOGaL46 /kmA== X-Gm-Message-State: AHQUAuYg13tAnFTqVxTrJLgjGL6HUneUj6Ce4JjlWa8yP+K2s3AQcEqw kqPdy3fFxsYUu2qM3oHWpMkVyzovmx9qY78Is+Dzyg== X-Google-Smtp-Source: AHgI3IbIoykylx1Eb5OdzvU5BzFxKEkkNBAEy/uC23EDiUGaNLJk6jD5sUo7NxRiGlNqlkDXf1DeKXsB/pkv2Z11puk= X-Received: by 2002:ac8:35f8:: with SMTP id l53mr18789518qtb.15.1549831862303; Sun, 10 Feb 2019 12:51:02 -0800 (PST) MIME-Version: 1.0 References: <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com> <201902101631.x1AGV1sa026790@slippy.cwsent.com> In-Reply-To: <201902101631.x1AGV1sa026790@slippy.cwsent.com> From: Warner Losh Date: Sun, 10 Feb 2019 15:50:50 -0500 Message-ID: Subject: Re: nosh init system To: Cy Schubert Cc: Garrett Cooper , "Conrad E. Meyer" , "Rodney W. Grimes" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: ED44A6A11F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=cz3SKcwN X-Spamd-Result: default: False [-5.39 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[a.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.86)[-0.861,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.52)[ip: (-8.09), ipnet: 2607:f8b0::/32(-2.47), asn: 15169(-1.95), country: US(-0.07)]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 20:51:05 -0000 On Sun, Feb 10, 2019, 11:34 AM Cy Schubert In message <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com>, Enji > Cooper writes > : > > On Feb 9, 2019, at 20:20, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.ne > > t> wrote: > > > > >> In message > > >> il.com> > > >> , Conrad Meyer writes: > > >>> Hi Cy, > > >>> > > >>>> On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert < > Cy.Schubert@cschubert.com> w > > rote: > > >>>> 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 whic= h > > >>>> other services depend on fail, only that branch of the startup tre= e > > >>>> 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 duri= ng > > >>>> 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 stoppin= g > > >>> 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. > > > > I=C3=A2=E2=82=AC=E2=84=A2m not sure if Conrad is referring to the isilo= n way of restarting > service > > s. If so, the isilon parallel start process would effectively wipe the > slate > > clean and restart everything if interrupted, which (because of the > nature of > > cleanvar, etc), would wipe out any and all pidfiles, resulting in in > weird se > > t of services which fail to start on next run through. > > > > In short, I think the fact that isilon didn=C3=A2=E2=82=AC=E2=84=A2t mo= unt tmpfs to /var/run > was b > > egging for pain, as it=C3=A2=E2=82=AC=E2=84=A2s a directory one should = only setup once at > boot. > > Regardless of whether they use tmpfs or not, services should be > constructed in a manner such that it should still work if the customer > chooses not to use tmpfs. > Correct. If we require this. That's a bug. This also goes for those who mount /usr separately like I do (which has > saved my bacon as recently as a couple of weeks ago). A change made to > one of the RC scripts assumed /usr was on rootfs. (When I raised the > issue the reply was "you should /usr on / anyway.") My point is that we > assume our way of setting up a server is the only way and we bulldoze. > In reality FreeBSD and prior to that commercial UNIX were set up > variously. It's only since Linux became so popular that it has been > assumed that one size fits all. > > These are two examples of why this approach doesn't work. POLA is > painful. > This would also be a bug. I'd just fix the bug. I know people don't want to think of these things, but we still support separate filesystems. Saying not to run that way is lame and unhelpful. > > > That being said, there are other pseudo services that aren=C3=A2=E2=82= =AC=E2=84=A2t > necessarily id > > empotent. If they run twice, the second run could result in breakage to > other > > dependent services run after them. > > Cleanvar being the focus of much of our discussion should be able to > determine it has run before. > > I'm purposely not discussing implementation details. > Yea. That's also a sloppy bug. In this case, there is no concept of restarting... we want to run it only once... maybe that is the real bug here: we don't adequately have a way to Express that notion. Of course the bigger issue is that this is the sort of thing you want to be 100% sure is done before anything that depends on it runs. When you have a complicated topology like our start graph, that makes doing stuff in parallel hard. Warner --=20 > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >