Date: Sat, 9 Feb 2019 19:29:17 -0800 From: Enji Cooper <yaneurabeya@gmail.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Wojciech Puchar <wojtek@puchar.net>, Sidju <lists@sidju.se>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Conrad Meyer <cem@freebsd.org> Subject: Re: nosh init system Message-ID: <EBB62B53-729B-42AA-89F0-BA2676ECAB84@gmail.com> In-Reply-To: <201902092334.x19NYtZe036559@slippy.cwsent.com> References: <201902092334.x19NYtZe036559@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 9, 2019, at 15:34, Cy Schubert <Cy.Schubert@cschubert.com> wrote: ... > I've been using NIS on FreeBSD for a couple of decades and still using=20 > it on my network. Except for one bad patch a few years ago it's been=20 > 100% solid. There are no startup or shutdown issues. My example of yp was probably a bad example for others to glom on to. Some real examples are netif vs routing, samba=E2=80=99s myriad of scripts, o= r restarting rpcbind (which doesn=E2=80=99t trigger a restart of mountd, nfs= d, etc). In the latter case, one can argue that the services can be made mor= e fault tolerant to their dependencies not being available (that=E2=80=99s o= ne part of a solution), however, the example of netif vs routing is much, mu= ch harder to solve without having an external service manager/monitor. > I don't see what's so "incredibly fragile" about rc(8). That's not to=20 > say there aren't better solutions, like SMF. >=20 > Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc=20= > script could fail hosing the boot or worse hosing the system*. Where a=20 > solution like SMF solves the problem is that should a service which=20 > other services depend on fail, only that branch of the startup tree=20 > would fail. In that scenario, if a service fails but sshd start, a=20 > sysadmin would still be able to login remotely to resolve the problem.=20 > So in this regard rc(8) is at a disadvantage. This is another item that yes, rc doesn=E2=80=99t solve properly. Good call (= I didn=E2=80=99t notice this shortcoming). > We could address the above paragraph by starting sshd earlier during=20 > boot thereby allowing the opportunity to fix remotely. Ehhhhhhh... this is probably not that easy. > Regarding SMF, it could be implemented by rc(8) invoking smf in similar=20= > fashion as Solaris does -- Solaris invokes it through inittab(5) -- or=20 > it could through a special yet to be determined entry in ttys(5). The=20 > Solaris approach is init(8)'s sole job, through the inittab(5) entry,=20 > is to restart smf, while smf does the rest. I prefer not to discuss=20 > implementation details right now, it's premature. >=20 > * Incredibly stupid people can hose SMF too. It is more complex. OTOH=20 > that complexity might scare the uninitiated from attempting something=20 > dumb. Quite frankly, service managers/monitors should manage services in a best ef= fort manner. Unless, there=E2=80=99s danger of something like filesystem cor= ruption occurring, I don=E2=80=99t think that a ton of effort should be put i= nto making complicated cases work. Cheers, -Enji=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBB62B53-729B-42AA-89F0-BA2676ECAB84>