Dave,

The normal response of any application with a boostrap failure is to
exit.  And as long as you have supervise instructed to keep the server
running, that's what it will do.  It's not a "death spiral".  :)

> > On Wed, May 13, 2020 at 10:24 AM David T. Lewis <lewis at mail.msen.com> wrote:
> > >
> > > OK, it should be back now, and hopefully the mail delivery will be working again.
> > >
> > > I don't know the details, but it looks like the startup script is looking for
> > > a file called "patch.st" to load. Chris had previously told me to rename that
> > > file to "patch.st.old", which I had done. But today I wanted to undo my
> > > earlier changes, and I renamed patch.st.old to patch.st.
> >
> > "Undoing your changes" would also mean undoing the image, which I
> > assume you had renamed to ".old"...?
> >
>
> No. I renamed the Sept 9, 2019 image per your direction, and I have not changed that.

I was referring to the proper way to "undo your changes".  If the
system doesn't come right up and it isn't obvious, just execute your
backout plan to backout 100% and regroup.  Putting the system into
some "third" state on-the-fly that is neither what you tested, nor
what the system was beforehand, is a recipe for problems.

A new system with an old patch is an invalid state for Personal
SqueakSource.  Removing that file is part of the normal deployment
process.  I'm sorry if it was confusing, but the system worked exactly
as designed by refusing to run an invalid configuration.  The message
in the log was clear, and you knew instantly what to do once you saw
it.

What needs fixing at this point is that image -- we need to be using
one built fresh with your MCConfigurations enhancement, so we know
what code our server is running, can maintain and collaborate on it
and be able to make fresh instantiations of it.

 - Chris





 - Chris