nosh init system

[Enji Cooper]

> On Feb 9, 2019, at 15:34, Cy Schubert <Cy.Schubert at cschubert.com> wrote:

...

> I've been using NIS on FreeBSD for a couple of decades and still using 
> it on my network. Except for one bad patch a few years ago it's been 
> 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’s myriad of scripts, or restarting rpcbind (which doesn’t trigger a restart of mountd, nfsd, etc). In the latter case, one can argue that the services can be made more fault tolerant to their dependencies not being available (that’s one part of a solution), however, the example of netif vs routing is much, much 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 
> say there aren't better solutions, like SMF.
> 
> 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. 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.

This is another item that yes, rc doesn’t solve properly. Good call (I didn’t notice this shortcoming).

> We could address the above paragraph by starting sshd earlier during 
> 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 
> fashion as Solaris does -- Solaris invokes it through inittab(5) -- or 
> it could through a special yet to be determined entry in ttys(5). The 
> Solaris approach is init(8)'s sole job, through the inittab(5) entry, 
> is to restart smf, while smf does the rest. I prefer not to discuss 
> implementation details right now, it's premature.
> 
> * Incredibly stupid people can hose SMF too. It is more complex. OTOH 
> that complexity might scare the uninitiated from attempting something 
> dumb.

Quite frankly, service managers/monitors should manage services in a best effort manner. Unless, there’s danger of something like filesystem corruption occurring, I don’t think that a ton of effort should be put into making complicated cases work.

Cheers,
-Enji