nosh init system

[Enji Cooper]

On Feb 9, 2019, at 20:20, Rodney W. Grimes <freebsd-rwg at pdx.rh.cn85.dnsmgr.net> wrote:

>> In message <CAG6CVpWXOA6r_aJcefxQBu2QZxprf1ZpDoTb4eb2JSwWsE2m+g at mail.gma
>> il.com>
>> , Conrad Meyer writes:
>>> Hi Cy,
>>> 
>>>> On Sat, Feb 9, 2019 at 3:35 PM Cy Schubert <Cy.Schubert at cschubert.com> wrote:
>>>> 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.

I’m not sure if Conrad is referring to the isilon way of restarting services. 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 set of services which fail to start on next run through.

In short, I think the fact that isilon didn’t mount tmpfs to /var/run was begging for pain, as it’s a directory one should only setup once at boot.

That being said, there are other pseudo services that aren’t necessarily idempotent. If they run twice, the second run could result in breakage to other dependent services run after them.

Thanks,
-Enji