nosh init system
Cy Schubert
Cy.Schubert at cschubert.com
Sun Feb 10 04:37:46 UTC 2019
In message <201902100420.x1A4KSxA064573 at pdx.rh.CN85.dnsmgr.net>,
"Rodney W. Gri
mes" writes:
> > 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> wr
> ote:
> > > > 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.
>
> >
> > 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.
>
> Much gets broken in the name of new features sadly.
That was my point. Tunnel vision.
>
> >
> > >
> > > 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.
>
> Shiny new things also come with shiny new problems, I would actually
> often rather repair a broken old something than get a new shiny
> something as I know the defects of the raty old something.
Agreed. Like building on a foundation of sand.
>
> > 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.
>
> We do not need to wait for BSDCan, there are more of us here on this
> list than at any dev summit.
True but whiteboards help. My point is let's itemize a list of issues
first. Write down (figuratively speaking) all ideas to address the
listed issues. Select the best ideas. Implement them.
>
> >
> > 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.
>
> It is rather simple to just drop the whole rc.d and rewrite
> /etc/rc for the embeded situtaion, going back to the 4.3 era.
>
> Though we might want to go over to the rc mailling list?
Excellent idea!
--
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.
More information about the freebsd-hackers
mailing list