Forums

Has anyone tried out Django version 3.0 on PythonAnywhere?

I kept getting intermittent errors when logged in... especially in the admin interface. They were '502-backend' errors, so unfortunately nothing shows up in the error logs. The admin interface would load maybe 1 in 10 times.

I was using Python 3.7.0. The errors went away as soon as I downgraded back to Django-2.2.8.

were you running it within a virtualenv? could it be that you had created a django2 webapp with django2 source code, and then tried to run django3 against it? what if you try creating a new django3 webapp from scratch?

Yes it was in a virtualenv and i was upgrading a django 2 app. So I'll create a new app from scratch in django 3 and see if that works and what the differences are.

Just wondering if anyone else had similar issues... :-)

The only potential issue that comes to mind with Django 3 is that it's not compatible with the version of Postgres we provide; apart from that it should work fine. Normally 502 errors should put something in the error logs, though... anyway, if you do have any issues with the freshly-installed site, we'd love to hear more :-)

I got the same 502 errors (notably on my admin interface) when applying Django 3.0 to my staging environment.

Strangely this doesn't seem to affect my local dev environnement with runserver.

It seems this has something to do with my WSGI config ? Here are the messages I get in server log :

2019-12-04 18:21:46 !!! uWSGI process 2 got Segmentation Fault !!!
2019-12-04 18:21:46 *** backtrace of 2 ***#012Ethikdo recette.ethikdo.co uWSGI worker 1(uwsgi_backtrace+0x2c) [0x46529c]#012Ethikdo recette.ethikdo.co uWSGI worker 1(uwsgi_segfault+0x21) [0x465661]#012/lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f0b3d5be4b0]#012/usr/lib/libpython3.7m.so.1.0(+0xe7bbf) [0x7f0b3a0a5bbf]#012/usr/lib/libpython3.7m.so.1.0(+0x13c441) [0x7f0b3a0fa441]#012/usr/lib/libpython3.7m.so.1.0(+0xf8283) [0x7f0b3a0b6283]#012/usr/lib/libpython3.7m.so.1.0(_PyObject_FastCallKeywords+0x104) [0x7f0b3a058024]#012/usr/lib/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x32aa) [0x7f0b3a02ad2a]#012/usr/lib/libpython3.7m.so.1.0(+0x688c0) [0x7f0b3a0268c0]#012/usr/lib/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x7060) [0x7f0b3a02eae0]#012/usr/lib/libpython3.7m.so.1.0(+0x688c0) [0x7f0b3a0268c0]#012/usr/lib/libpython3.7m.so.1.0(_PyFunction_FastCallDict+0x2be) [0x7f0b3a0578ae]#012/usr/lib/libpython3.7m.so.1.0(_PyObject_Call_Prepend+0xcd) [0x7f0b3a058a2d]#012/usr/lib/libpython3.7m.so.1.0(+0xfdc01) [0
2019-12-04 18:21:47 DAMN ! worker 1 (pid: 2) died :( trying respawn ...
2019-12-04 18:21:47 Respawned uWSGI worker 1 (new pid: 16)
2019-12-04 18:21:47 spawned 2 offload threads for uWSGI worker 1

Thanks, that's really useful! It looks like uWSGI, the program that we use to interface between the web server and your Python code, is crashing. That's not a problem with your code, and it's something we clearly have to investigate. We'll post more here when we know more.

OK, so a simple install of Django 3.0 doesn't crash, so there's clearly some interaction with something else that's triggering this bug.

@antoningrele, @justinhui -- could we take a look at your files just to see if there's (for example) some Python package that you're both using, or something like that?

Sure thing. I sent you an email with the account that is affected by the issue (as it is not the one I'm using now).

Yes that would be great. I've popped some more details on an email

I just created a Django 3 app from scratch with just Django 3 and it's dependencies installed on a virtualenv with Python 3.7

I still get the same issues, although not quite as frequently as before, when logging into admin interface:

2019-12-05 09:33:20 !!! uWSGI process 5 got Segmentation Fault !!!
2019-12-05 09:33:20 *** backtrace of 5 ***#012justinhui testing.lyricrobot.rocks uWSGI worker 2(uwsgi_backtrace+0x2c) [0x46529c]#012justinhui testing.lyricrobot.rocks uWSGI worker 2(uwsgi_segfault+0x21) [0x465661]#012/lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f8f36c7b4b0]#012/usr/lib/libpython3.7m.so.1.0(+0xe7bbf) [0x7f8f33762bbf]#012/usr/lib/libpython3.7m.so.1.0(+0x13c441) [0x7f8f337b7441]#012/usr/lib/libpython3.7m.so.1.0(+0xf8283) [0x7f8f33773283]#012/usr/lib/libpython3.7m.so.1.0(_PyObject_FastCallKeywords+0x104) [0x7f8f33715024]#012/usr/lib/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x32aa) [0x7f8f336e7d2a]#012/usr/lib/libpython3.7m.so.1.0(+0x688c0) [0x7f8f336e38c0]#012/usr/lib/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x7060) [0x7f8f336ebae0]#012/usr/lib/libpython3.7m.so.1.0(+0x688c0) [0x7f8f336e38c0]#012/usr/lib/libpython3.7m.so.1.0(_PyFunction_FastCallDict+0x2be) [0x7f8f337148ae]#012/usr/lib/libpython3.7m.so.1.0(_PyObject_Call_Prepend+0xcd) [0x7f8f33715a2d]#012/usr/lib/libpython3.
2019-12-05 09:33:21 DAMN ! worker 2 (pid: 5) died :( trying respawn ...
2019-12-05 09:33:21 Respawned uWSGI worker 2 (new pid: 13)
2019-12-05 09:33:21 spawned 2 offload threads for uWSGI worker 2

Thanks for the emails! We'll look into that and respond over email, and will post back here when we have some results.

OK, we think we may have pinpointed the issue. We were able to reproduce it by using our "earlgrey" system image, but not using our most recent one, "fishnchips". We think it might be related to the version of Python 3.7 we have installed in earlgrey, which is 3.7.0. Fishnchips has 3.7.5,which has a number of bugfixes.

We can update your accounts to use fishnchips, but one word of warning first -- because changing the system image upgrades a lot of the pre-installed Python packages, any code that you have that relies on those packages might break if it's not compatible with the new versions. Also, because the new image has newer versions of Python, if you have any virtualenvs, you may need to rebuild them. If you're happy to go ahead despite that, just let us know and we'll switch you over.

Yes that has worked. Thank you very much

Excellent, thanks for confirming!

This post just saved me from hours of headaches. Thank you for sharing, i had to downgrade my django to 2.17 before it eventually worked out. I initially thought it was the admin CSS that wasnt loading, was about to start a new topic on the issue before i came across this post. Today is not the day i give up, lol.

yay! do let us know if you want the new system image as well! (that would work with Django 3, but it may break existing code and you will need to rebuild virtualenvs)

Can you please shed more light on the whole new system image? I don't quite get. Thank you in anticipation.

Each account has a system image -- you can think of it as being the version of the operating system that your account uses. It determines things like the versions of Python that are available to you, the installed OS packages, and which versions of the various pre-installed Python modules you have. We can easily change the system image for your account if you like, and all of your own files and data will be safe. But because the versions of Python and the pre-installed packages change, you might have to change your code to work with those upgraded components.

The specific problem with Django 3 appears to be that it triggers a bug in Python 3.7.0, which makes it crash. Our old system image, "earlgrey", has Python 3.7.0, hence the problem that you see if you're using that system image. Our latest system image, "fishnchips", has Python 3.7.5, so it works fine.

This thread is just one example of the reason I use pythonanywhere. A lot of the alternatives are not shit, but pythonanywere is gold. Thanks.

Thanks!

thanks for the tip. had the same issue. downgrading to python 3.6 (from 3.7) by setting up a new virtual env fixed the problem. i recently upgraded to django 3 as well and ran into the same issue.

How do I find out what the current system image I am using is?

@TheChallengerLeague thanks for confirming!

@jimbochou77 -- you're currently on earlgrey, which is the one with 3.7.0 (and thus with this problem with Django 3.0). You can check by looking at the top of our batteries included page.

I have the same problem as I solve

I see that you asked for a system image update in another thread -- now that that is done, that should fix the problem.

I'm apparently having the same problem:

2020-11-13 13:54:08 !!! uWSGI process 5 got Segmentation Fault !!!
2020-11-13 13:54:08 *** backtrace of 5 ***#012teppo teppo.pythonanywhere.com uWSGI worker 2(uwsgi_backtrace+0x2c) [0x46529c]#012teppo teppo.pythonanywhere.com uWSGI worker 2(uwsgi_segfault+0x21) [0x465661]#012/lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f0341b4e4b0]#012/usr/lib/libpython3.7m.so.1.0(+0xe7bbf) [0x7f033e635bbf]#012/usr/lib/libpython3.7m.so.1.0(+0x13c441) [0x7f033e68a441]#012/usr/lib/libpython3.7m.so.1.0(+0xf8283) [0x7f033e646283]#012/usr/lib/libpython3.7m.so.1.0(_PyObject_FastCallKeywords+0x104) [0x7f033e5e8024]#012/usr/lib/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x32aa) [0x7f033e5bad2a]#012/usr/lib/libpython3.7m.so.1.0(+0x688c0) [0x7f033e5b68c0]#012/usr/lib/libpython3.7m.so.1.0(_PyEval_EvalFrameDefault+0x7060) [0x7f033e5beae0]#012/usr/lib/libpython3.7m.so.1.0(+0x688c0) [0x7f033e5b68c0]#012/usr/lib/libpython3.7m.so.1.0(_PyFunction_FastCallDict+0x2be) [0x7f033e5e78ae]#012/usr/lib/libpython3.7m.so.1.0(_PyObject_Call_Prepend+0xcd) [0x7f033e5e8a2d]#012/usr/lib/libpython3.7m.so.1.

Is possible to get a system image update?

Also, it might be a good idea to include some information about this on the help page https://help.pythonanywhere.com/pages/DeployExistingDjangoProject

@teppo It's done for you.

Thanks @fjl ! I'll try it out asap.

Yes, @fjl, it seems to be working great. Thank you!

One detail, though: the default Python3 in Debian Buster seems to be 3.7.3 and this newer PythonAnywhere system image, "fishnchips", has Python 3.7.5. I'm hoping that the differences are not huge, but would there be an easy way for me to get the exact same Python version running here at PythonAnywhere and on the Debian Buster i'm using for development..?

You can use python --version

@glenn, yes python --version tells me which version I'm using.

PythonAnywhere Bash console:

$ python --version
Python 3.7.5

Debian Buster Bash console:

$ python --version
Python 3.7.3

However, for what I understand, you are only able to create a virtualenv with the available python versions and not specify the minor version:

$ mkvirtualenv myvirtualenv --python=/usr/bin/python3.7.3
The path /usr/bin/python3.7.3 (from --python=/usr/bin/python3.7.3) does not exist

So, I should maybe get the 3.7.5 on my Debian and create a virtualenv with that..?

It should be fine. Minor versions are feature compatible. Newer ones contain just bug fixes.

Would you be able to upgrade my image as well? I am getting the same bug with Django 3. Thanks.

I think it is possible to manually change the system image from the accounts page now.

Take a look at https://help.pythonanywhere.com/pages/ChangingSystemImage