thorrak/fermentrack

Upgrade issue - glibc 2.28

Wobbly74 opened this issue · 7 comments

Hi - I ran an upgrade today to pull the latest version of Fermentrack via the GUI. When it finished upgrading and restarted it didn't come back up. I poked around a bit and when I use updateCronCircus.sh to either try and start it or check the status it gives me a traceback indicating that it needs glibc 2.28, specifically:

updateCronCircus.txt

When I try and manually run upgrade3.sh I get the same error in the log file, and a segmentation fault when running it.

I'm running raspbian stretch and have glibc 2.24. Is there a build available that I can upgrade to that doesn't come with the 2.28 dependency? If not is it possible to downgrade to the version prior to the December udpate?

Are you on the docker or non-docker version?

Non docker

You can check out a specific commit and manually install if you like -- the last commit before I made changes to the requirements was b650510 -- but I'm not sure that this will solve the issue. There appears to have been an update to libzmq which is creating problems, and I'm not sure if there is a way to specifically target an earlier version of libzmq to solve this issue. That said - checking out that specific commit, reinstalling requirements via pip, and relaunching may solve your problem and certainly is worth a shot. If nothing else, you can also try reverting this specific change (the version of pyzmq) and see if that helps resolve the issue.

Unfortunately, you just hit on why I no longer support non-docker installs. It's almost impossible to predict what environments people are running, and be able to provide either wheels or binaries to match.

While it isn't helpful in resolving this issue, I did want to add some color just in case you were curious (or someone else found this issue):

One of the early decisions in building Fermentrack was to use circus to manage BrewPi-script and tilt monitor processes. Circus seemed perfect for this use case as it natively supports being controlled from within Python, but - as can be seen from the project's byline - it is "A Process & Socket Manager built with zmq" - the use of zmq is at the core of circus's functionality. Unfortunately for us, for whatever reason zmq tends to cause a lot of problems. (This issue is at least the second unique instance of some kind of behind-the-scenes change to zmq/pyzmq breaking Fermentrack)

I'd like to move away from circus to something that doesn't require zmq (supervisor?) but I think that would be a pretty big refactor as I don't believe Supervisor can be controlled quite as neatly from within Python. It's on the list, but it's hard to get motivated to do a massive rip-and-rewrite for something that works in the supported configuration.

Bear with - I'm not overly technical... so I tried checking out the earlier commit:
git checkout b650510

Then updated requirements via pip:
pip3 install --no-cache-dir -U -r requirements.txt --upgrade &>> log/upgrade.log

This reverted the requirements/base.txt back to pyzmq 19.0.2.

Trying to start fermentrack via updateCronCircus.sh resulted in the same error. Restarting the pi resulted in the same (still requiring glibc 2.28). I'm guessing the only resolution here is to reinstall using the docker image and reconfiguring from scratch?

Bear with - I'm not overly technical... so I tried checking out the earlier commit: git checkout b650510

Then updated requirements via pip: pip3 install --no-cache-dir -U -r requirements.txt --upgrade &>> log/upgrade.log

This reverted the requirements/base.txt back to pyzmq 19.0.2.

Trying to start fermentrack via updateCronCircus.sh resulted in the same error. Restarting the pi resulted in the same (still requiring glibc 2.28). I'm guessing the only resolution here is to reinstall using the docker image and reconfiguring from scratch?

This is what I was afraid of -- the upgrade is in libzmq, which we don't have control over (and which I think is getting bundled with the wheel). Try this:

pip3 install --no-cache-dir --upgrade pyzmq==19.0.2 --no-binary :all:

It should take a (relatively) long time as it will rebuild the wheel from scratch using (hopefully) whatever version of libzmq you have available on your system.

Unfortunately that just failed fairly early on during compilation, on including python.h (which seems indicative of a larger issue).

I'm also unable to install the latest version using docker as I've run into the same problem as others have with the ancient version of docker compose on stretch (1.80) and unsure as to how to upgrade it, as reinstalling docker and docker compose just installs the same (old) versions. Which means I think the only alternative now would be to upgrade from stretch to the latest distribution. I'm thinking it might be easier to start a brand new image and reinstall everything given I primarily just use craftbeerpi for kettle control and fermentrack for fermentation control.

Might be worth putting some sort of health warning on this latest update, as anyone updating to it using stretch will no doubt end up in the same position.