Date: Sun, 10 Feb 2019 07:43:32 -0800 From: Enji Cooper <yaneurabeya@gmail.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, cem@freebsd.org Subject: Re: nosh init system Message-ID: <43C091FC-18ED-49DF-A488-784DC2329D52@gmail.com> In-Reply-To: <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net> References: <201902100420.x1A4KSxA064573@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 9, 2019, at 20:20, Rodney W. Grimes <freebsd-rwg@pdx.rh.cn85.dnsmgr.n= et> wrote: >> In message <CAG6CVpWXOA6r_aJcefxQBu2QZxprf1ZpDoTb4eb2JSwWsE2m+g@mail.gma >> il.com> >> , Conrad Meyer writes: >>> Hi Cy, >>>=20 >>>> 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. >>>=20 >>> 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. :-) >>>=20 >>>> 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. >>>=20 >>> Right; that's a great example. >>>=20 >>>> 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. >>>>=20 >>>> We could address the above paragraph by starting sshd earlier during >>>> boot thereby allowing the opportunity to fix remotely. >>>=20 >>> 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 :-). >>=20 >> I'd rather see SMF but a number felt a CDDL licensed init was=20 >> unacceptable -- except for the fact that SMF doesn't replace init. >>=20 >>>=20 >>> 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. >=20 > 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=E2=80=99m not sure if Conrad is referring to the isilon way of restarting s= ervices. If so, the isilon parallel start process would effectively wipe the= slate clean and restart everything if interrupted, which (because of the na= ture of cleanvar, etc), would wipe out any and all pidfiles, resulting in in= weird set of services which fail to start on next run through. In short, I think the fact that isilon didn=E2=80=99t mount tmpfs to /var/ru= n was begging for pain, as it=E2=80=99s a directory one should only setup on= ce at boot. That being said, there are other pseudo services that aren=E2=80=99t necessa= rily idempotent. If they run twice, the second run could result in breakage t= o other dependent services run after them. Thanks, -Enji=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43C091FC-18ED-49DF-A488-784DC2329D52>