nosh init system

[Cy Schubert]

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 wasn't that way 10-15 years ago. It's evolved to become this. Even 
if we stay with rc(8), quickly cobbling together a patch isn't going to 
fix it long term. Whether we use another init, an add-on like SMF, or 
make rc(8) more robust, it will not be fixed by a simple tweak here or 
there.

>
> E.g., the major pain point we run into repeatedly with restarted boot
> is that cleanvar / cleartmp run again.  This breaks ld-elf.so.hints
> cache (anything linking /usr/local libraries — hope your admin is
> running base sshd and not openssh-portable!) as well as wiping out
> /var/run pid files (breaking "already running?" rc pid checks).  As a
> result, services get double-started.
>
> Cleanvar could maybe be improved to avoid this problem — e.g., we
> could coordinate with the kernel to set a per-boot, persisted flag
> that cleanvar has completed, even if rc(8) exits — but the broad class
> of problems would remain (rc.d autostart is stateful, but any partial
> failure destroys all state).

This needs more than improving cleanvar or some other script. It's like 
whack-a-mole. (The rest of this not specifically talking to you 
Conrad.) This is why every one to two months this topic comes up again 
and again and again. It's a pain point. (And also the shiny new object 
syndrome.) Various people suggest their favourite init(8) replacement 
and the bikeshed starts up again.

To avoid bikeshedding this to death again, we enumerated two issues so 
far. Let's continue to list issues. I also think that this should be a 
BSDCan devsummit whiteboard topic where we list issues in one column 
and next to it we list possible solutions, after listing all the issues 
first. And finally if this is too large for one person to work on, 
assign the various issues to willing developers.

One final thought. init(8) and rc(8) requirements for desktop/laptop, 
server, embedded, and mobile are probably different enough that their 
requirements may compete with each other. Some embedded applications 
may desire a simple rc(8) whereas server or desktop a heavier weight 
solution.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.