[mythtv-users] Backend quits functioning
wepprop at sbcglobal.net
Mon May 29 22:38:16 UTC 2006
Mark Knecht wrote:
> Thanks, but it's not so easy.
> It's a huge job to upgrade here. I've got a back-end machine with
> two tuners and then 5 separate frontend machines accessing it. Since
> the Myth devs decided that frontends and backends must match versions
> it's too many machines to deal with all at once. I have a wife and kid
> watching these things daily. It goes down and I'm in trouble! No
> Possibly in July I'll get a break as they go off on vacation. Until
> then I'm stuck.
> I'll hold out some hope that 0.19 fixes this crash problem.
First, please don't get the idea that 0.19 is a panacea for all
problems. I ran 0.18.1 for 8 months without a single hiccup but after 3
months on several versions of 0.19 and subs, I'd go back to 0.18.1 in a
heartbeat if I could. Unfortunately I waited so long to decide I wanted
to, that it was no longer easy to do so.
On the other hand, with a total of two backends and four frontends, I'm
familiar with the problems of upgrading you mention and I've pretty much
got it down to a science. For me, the key to making upgrading easy is
the ability to quickly go back to the previous (working) version if
something goes wrong during the upgrade. After trying several methods,
it finally turned out to be easiest for me to install Myth from source.
First, I use apt or yum or smart or source or whatever it takes to
configure all the boxes so I can compile Myth on it.
Then I use ssh to log in to each box remotely and compile ('make') the
new version but I don't do a 'make install'. Once I have the new
version compiled on all the boxes, I then find a free hour or so when no
one is watching TV or recording anything when I can perform the
upgrade. 7:00 am Sunday morning always seems to be available... :)
To perform the actual upgrade, first I save the database per the
instructions in the docs. Downgrading is easy with a copy of the
previous database but it's darn near impossible without it. Next I ssh
to each box and stop all the backends. Finally, I go back to the new
version source directory each box and do the 'make install'. Then I
restart the backends, master first, and then the frontends.
If something goes wrong, I stop everything, delete any test recordings
I've made since the upgrade, drop the database using the instructions in
the docs, and restore the previous version of the database from the
backup. Then I go back to the source directory for the previous (older
but working) version on each box and do 'make install' again (which
overwrites the new version binaries with the older version binaries).
Then I start the backends, then the frontends. I can do the whole
thing, installing a new version, testing it, and downgrading to the old
version, in well under an hour.
The one drawback is that the longer you spend on the newer version, what
with new recordings and new schedules, the more painful it is to go back
to the older version.
If anyone is contemplating changing from an rpm-style install to a
source install, uninstall the rpm version before installing the source
compiled version: It's likely they don't install to the same directory
and you *don't* want to deal with having two versions installed at the
same time. If necessary, first install the same version you had
installed with rpm's as step one, then do the upgrade to the newer
version. That will ensure the previous version binaries are easily
available should you need to downgrade. Of course, there's other ways
to handle that step, such as keeping the old version rpm's handy,
renaming the old version binaries in-place, etc.
Just my experiences. YMMV.
More information about the mythtv-users