-
Hi baby buddies, I'm running Baby Buddy on a Linode "Nanode" instance, and it's been working flawlessly since April. I've installed it following the instructions in the install guide from github, for a manual deployment. The Nanode is running Debian 10 (Buster), and has, as mentioned worked flawlessly since April when I installed it. I haven't touched the config of either Baby Buddy or Debian in that timeframe, but I'm now no longer able to load the sleep pattern. When loading example.com/children/child/reports/sleep/pattern I get a white page that says: Server error (500) I checked the nginx error_log in I took a look at
Am I looking in the right place for any errors, or do Baby Buddy log errors somewhere else as well? |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 1 reply
-
The easiest way to get detailed error information is to enable debug mode and try to the load graph. You can do by setting a What version of Baby Buddy are you running? There have been a few bug fixes related to graphs recently so you may also want to try updating to the latest version as well. |
Beta Was this translation helpful? Give feedback.
-
Thank you for your very fast reply! I'm running version: v1.5.1 (4df001c). Good shout on potentially updating to the latest version. Can I go straight to the latest, 1.9.1 release, or should I update in steps to some of the previous updates first? And also, on that, is there a guide on how not to nuke your install when updating manually? (: I will change DEBUG to True in the base.py file, and see what error output I get. Will the error output be sent directly to the error page, or should I still look in the babybuddy.log file? Thanks a lot! |
Beta Was this translation helpful? Give feedback.
-
You should be able to up the latest version fine, just make sure to run migrations after updating. And definitely make a database backup beforehand just in case. Debug output will go to browser. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your help @cdubz. I tried
After restarting uwsgi and nginx, I was met with a white page saying "internal server error" when loading, so I quickly rolled back as I was under some pressure to make this excellent app work again (: I'm sorry for being so helpless here, but do you know if there's something else I should have done before running After rolling back to 1.5.1, I enabled the debugging mode, and when trying to view the sleep pattern chart, I now get a much more verbatim error message which has this at the core:
I will try doing another upgrade later in the week where I don't stash anything, that might fix the error message I got from running migrate. Upgrading to 1.9.1 definitely seems like an easier solution, if I can get the update to run properly. |
Beta Was this translation helpful? Give feedback.
-
Ah you pretty far back so you'll need to re-run If you can share the diffs for the settings and urls files I can possible also help you get that a bit better sorted, if necessary. |
Beta Was this translation helpful? Give feedback.
-
Perfect. I think I will just try the update, now that I understand the process a bit better. I was thinking of making a copy of the Sorry if these are very stupid questions, I have very little experience with pip and virtual environments (: |
Beta Was this translation helpful? Give feedback.
-
No worries. Python's package management system is kind of shitshow so there are no stupid questions (: Copying the folder as a backup should work because it should have the Also you may need to want to So my recommendation here is:
And if you run in to irreparable issues anywhere along the way -- just restore the Linode instance backup or unpack the directory contents. |
Beta Was this translation helpful? Give feedback.
No worries. Python's package management system is kind of shitshow so there are no stupid questions (:
Copying the folder as a backup should work because it should have the
.git
and.venv
(where virtual environment libraries live) folders. That said, I'd recommend just creating a backup of the instance that you can fully restore from if something goes wrong (assuming that's possible with Linode -- I have never used it). Also, in theory, if something did get hosed you should still be able to checkout v1.4.1 and re-runpipenv install --three
to get the correct packages back in place.Also you may need to want to
export PIPENV_VENV_IN_PROJECT=1
before anypipenv install
commands. I don't think…