I have been working on a side project using django and django rest framework. There is even an active version running in the cloud currently without any issue. I wanted to make some minor changes on the code base but while using the django admin page it crashes silently. I haven't changed anything in the code until now.
[2022-08-31 13:39:10 +0200] [8801] [INFO] Starting gunicorn 20.1.0
[2022-08-31 13:39:10 +0200] [8801] [INFO] Listening at: http://127.0.0.1:8000 (8801)
[2022-08-31 13:39:10 +0200] [8801] [INFO] Using worker: sync
[2022-08-31 13:39:10 +0200] [8802] [INFO] Booting worker with pid: 8802
[2022-08-31 13:39:18 +0200] [8801] [WARNING] Worker with pid 8802 was terminated due to signal 11
[2022-08-31 13:39:18 +0200] [8810] [INFO] Booting worker with pid: 8810
[2022-08-31 13:39:23 +0200] [8801] [WARNING] Worker with pid 8810 was terminated due to signal 11
[2022-08-31 13:39:23 +0200] [8814] [INFO] Booting worker with pid: 8814
Same happens with python manage.py runserver command.
I'm using a virtual environment with python 3.9
Signal 11 (SIGSEGV, also known as segmentation violation) means that the program accessed a memory location that was not assigned to it.
That's usually a bug in a program. So if you're writing your own program, that's the most likely cause.
It can also commonly occur with some hardware malfunctions.
Related
I just re-deployed an application in the new Eco Dyno and provisioning a new PostgreSQL datbase, however after deploying successfully, when I try to open the application, this HTTP error is returned ERR_CONNECTION_TIMED_OUT and the application never opens. I also updated the stack from heroku-20 to heroku-22 and it is not working on both. Is there any additional configuration that I need to complete?
This is the log from the latest deploy
2023-01-30T22:13:55.000000+00:00 app[api]: Build started by user farmacia#aselsi.org
2023-01-30T22:14:32.846408+00:00 app[api]: Deploy c6f350bc by user farmacia#aselsi.org
2023-01-30T22:14:32.846408+00:00 app[api]: Release v23 created by user farmacia#aselsi.org
2023-01-30T22:14:33.126404+00:00 heroku[web.1]: Restarting
2023-01-30T22:14:33.141734+00:00 heroku[web.1]: State changed from up to starting
2023-01-30T22:14:34.066230+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2023-01-30T22:14:34.109732+00:00 app[web.1]: [2023-01-30 22:14:34 +0000] [4] [INFO] Handling signal: term
2023-01-30T22:14:34.109979+00:00 app[web.1]: [2023-01-30 22:14:34 +0000] [9] [INFO] Worker exiting (pid: 9)
2023-01-30T22:14:34.110205+00:00 app[web.1]: [2023-01-30 22:14:34 +0000] [10] [INFO] Worker exiting (pid: 10)
2023-01-30T22:14:34.310286+00:00 app[web.1]: [2023-01-30 22:14:34 +0000] [4] [INFO] Shutting down: Master
2023-01-30T22:14:34.461478+00:00 heroku[web.1]: Process exited with status 0
2023-01-30T22:14:35.372879+00:00 heroku[web.1]: Starting process with command `gunicorn aselsi.wsgi`
2023-01-30T22:14:36.441571+00:00 app[web.1]: [2023-01-30 22:14:36 +0000] [4] [INFO] Starting gunicorn 20.1.0
2023-01-30T22:14:36.441910+00:00 app[web.1]: [2023-01-30 22:14:36 +0000] [4] [INFO] Listening at: http://0.0.0.0:54892 (4)
2023-01-30T22:14:36.441956+00:00 app[web.1]: [2023-01-30 22:14:36 +0000] [4] [INFO] Using worker: sync
2023-01-30T22:14:36.447323+00:00 app[web.1]: [2023-01-30 22:14:36 +0000] [9] [INFO] Booting worker with pid: 9
2023-01-30T22:14:36.521146+00:00 app[web.1]: [2023-01-30 22:14:36 +0000] [10] [INFO] Booting worker with pid: 10
2023-01-30T22:14:36.588676+00:00 heroku[web.1]: State changed from starting to up
2023-01-30T22:14:37.000000+00:00 app[api]: Build succeeded
2023-01-30T22:17:56.524340+00:00 app[api]: Starting process with command `python manage.py migrate` by user farmacia#aselsi.org
2023-01-30T22:17:59.955485+00:00 heroku[run.7847]: State changed from starting to up
2023-01-30T22:18:00.056845+00:00 heroku[run.7847]: Awaiting client
2023-01-30T22:18:00.078452+00:00 heroku[run.7847]: Starting process with command `python manage.py migrate`
2023-01-30T22:18:05.101096+00:00 heroku[run.7847]: Process exited with status 0
2023-01-30T22:18:05.175678+00:00 heroku[run.7847]: State changed from up to complete
I re deployed from github making minor changes on the code to be sure that the most recent changes are being deployed properly. I updated the heroku stack to make sure that was not the problem. I also ran migrations after the application is deployed and they are applied successfully so the only problem is that the site is not reachable for some reason.
Ive deployed a few heroku webapps. But for some reason, this one is giving me pain.
with
git push heroku main
my app starts, and is deployed. No issues whatsoever. But when I click the link, I get a this site cant be reached. ____ took too long to respond
Upon checking the logs, there seems to be no errors:
2022-09-01T17:46:08.937248+00:00 heroku[web.1]: State changed from down to starting
2022-09-01T17:46:12.101512+00:00 heroku[web.1]: Starting process with command `gunicorn wsgi:app`
2022-09-01T17:46:13.204452+00:00 app[web.1]: [2022-09-01 17:46:13 +0000] [4] [INFO] Starting gunicorn 20.1.0
2022-09-01T17:46:13.204789+00:00 app[web.1]: [2022-09-01 17:46:13 +0000] [4] [INFO] Listening at: http://0.0.0.0:42097 (4)
2022-09-01T17:46:13.204842+00:00 app[web.1]: [2022-09-01 17:46:13 +0000] [4] [INFO] Using worker: sync
2022-09-01T17:46:13.207772+00:00 app[web.1]: [2022-09-01 17:46:13 +0000] [9] [INFO] Booting worker with pid: 9
2022-09-01T17:46:13.268559+00:00 app[web.1]: [2022-09-01 17:46:13 +0000] [10] [INFO] Booting worker with pid: 10
2022-09-01T17:46:13.737219+00:00 heroku[web.1]: State changed from starting to up
What is going on?
It runs completely fine when I run the wsgi.py file locally. Im so confused why its taking too long to respond because It's just rendering an HTML template.
In my Django settings and on my machine I have utc+3 configured time so the expectations were to get all logs in utc+3, but turned out, that actually they are pretty messy:
[2017-08-08 10:29:22 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-08-08 10:29:22 +0000] [1] [DEBUG] Arbiter booted
[2017-08-08 10:29:22 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000
[2017-08-08 10:29:22 +0000] [1] [INFO] Using worker: sync
[2017-08-08 10:29:22 +0000] [7] [INFO] Booting worker with pid: 7
[2017-08-08 10:29:23 +0000] [1] [DEBUG] 1 worker
[2017-08-08 13:29:26 +0300] [7] [INFO] [dashboard.views:9] Displaying menu
Settings:
TIME_ZONE = 'Europe/Moscow'
USE_TZ = True
Maybe you can provide some hints/information how to configure or debug it?
For a moment I thought that this is a gunicorn's problem, but it uses Django settings soo I have no idea what's wrong :/
Gunicorn logging time do not relay on Django timezone, but in the local machine one, so to get the right timezone you should configure your local machine and how to do it depends in what OS is running on it.
For Debian/Ubuntu:
sudo dpkg-reconfigure tzdata
Follow the directions in the terminal.
The timezone info is saved in /etc/timezone - which can be edited or used below
If you are using CentOS you can check it in this article.
For other options, check it in Google.
Hope that it helps.
So, the timestamps were correct, but different because of my company proxy settings. Also it turned out that is best way to handle different time zones is just use utc everywhere except presentation to user.
I am trying to implement nginx + django + gunicorn for my project deployment. I am taking the help of following article:
http://tutos.readthedocs.io/en/latest/source/ndg.html . I followed the steps as described. Now, I am trying to start gunicorn. What am I getting at the screen is:
$ gunicorn ourcase.wsgi:application
[2016-05-19 19:24:25 +0000] [9290] [INFO] Starting gunicorn 19.5.0
[2016-05-19 19:24:25 +0000] [9290] [INFO] Listening at: http://127.0.0.1:8000 (9290)
[2016-05-19 19:24:25 +0000] [9290] [INFO] Using worker: sync
[2016-05-19 19:24:25 +0000] [9293] [INFO] Booting worker with pid: 9293
Since, I am new to nginx & gunicorn, I am not sure whether the above is an error or not. I am getting nothing in error log
cat /var/log/nginx/error.log
It prints nothing on the screen. Please help me to solve this.
That output means that the process is running. Which is what you want. You should try accessing the URL from the browser directly after running the command without pressing ctrl+c.
As a side note you can write a bash script to do this which will make it easier to add arguments to the gunicorn commands.
I have a gist that does just that. https://gist.github.com/marcusshepp/129c822e2065e20122d8
Let me know what other questions you might have and I'll add a comment.
I have Django app using StreamingHttpResponse that fails when gunicorn worker times out. Basically extending timeout is not an option as streaming can take longer as it depends on network speed. Web server won't time out as is actually doing something but gunicorn workers seems to not recognize it.
I am aware of a choice between sync and async workers supported by gunicorn and using for example gevent.
it starts:
gunicorn -D -p /path/to/django.pid --bind 127.0.0.1:8000 --workers 2 -k gevent --worker-connections 10 --max-requests 100 myapp.wsgi:application
gunicorn log:
[2016-01-21 15:12:34 +0000] [30333] [INFO] Listening at: ...
[2016-01-21 15:12:34 +0000] [30333] [INFO] Using worker: gevent
[2016-01-21 15:14:22 +0000] [30338] [DEBUG] GET /url/1/
[2016-01-21 15:14:22 +0000] [30338] [DEBUG] Closing connection.
[2016-01-21 15:14:24 +0000] [30343] [DEBUG] GET /download/1/
...
[2016-01-21 15:15:43 +0000] [30333] [CRITICAL] WORKER TIMEOUT (pid:30343)
[2016-01-21 15:15:43 +0000] [30343] [DEBUG] Closing connection.
[2016-01-21 15:15:43 +0000] [30343] [INFO] Worker exiting (pid: 30343)
[2016-01-21 15:15:43 +0000] [31203] [INFO] Booting worker with pid: 31203
nginx log
2016/01/21 15:15:43 [error] 23160#0: *10849 upstream prematurely closed connection while reading upstream...
Why deploying the same app using fastcgi and flup never exposed that problem? Anyone could advice?