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.
Related
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.
I am working on a Windows 10 machine using Ubuntu inside WSL. I did this because I cannot get gunicorn to work as I've researched it is not available in Windows. I can successfully run my app using my docker-compose file within my WSL Ubuntu perfectly fine. I then run the gunicorn myapp.wsgi command and the server spins up with the terminal giving me the following output:
[2021-09-16 19:11:53 +0000] [25] [INFO] Starting gunicorn 20.1.0
[2021-09-16 19:11:53 +0000] [25] [INFO] Listening at: http://127.0.0.1:8000 (25)
[2021-09-16 19:11:53 +0000] [25] [INFO] Using worker: sync
[2021-09-16 19:11:53 +0000] [26] [INFO] Booting worker with pid: 26
However, I cannot connect to my site at localhost:8000. I also did a curl request against the localhost:8000 from inside my docker container and got a 302 error.
I've researched using gunicorn, mod_wsgi and uwsgi, all given as options in the Django documentation. However, I want to use gunicorn or uwsgi to have access to either nginx or Apache (plus the documentation on mod_wsgi has a dead link for the windows install file). Does anyone have suggestions on how I can get this to work?
We have a Google Cloud run application that runs at 1am every morning to ingest, process, and output some data files. Currently, we have max concurrency, as timing is important.
Over the past weeks we have noticed several errors generated by the platform.
The Cloud Run logs themselves show Shutting down: Master
At a similar timestamp, a logging sink picks up
The request failed because either the HTTP response was malformed or connection to the instance had an error.
We have modified the instances and concurrency, as well as memory and vCPUs available, and they just show the same error but generated over a longer period of time.
There are no other errors or logs generated to give us any further info.
Any ideas where we may be going wrong?
Edit:
The full trace from the Cloud Run log is below
[INFO] Starting gunicorn 20.0.4
[1] [INFO] Listening at: http://0.0.0.0:8080 (1)
[1] [INFO] Using worker: sync
[4] [INFO] Booting worker with pid: 4
[5] [INFO] Booting worker with pid: 5
[6] [INFO] Booting worker with pid: 6
[1] [INFO] Handling signal: term
[6] [INFO] Worker exiting (pid: 6)
[5] [INFO] Worker exiting (pid: 5)
[4] [INFO] Worker exiting (pid: 4)
[1] [INFO] Shutting down: Master
My situation was the same.
I sloved it by stop the firewall.
I have a script that hits a simple API on all my servers every hour to ensure they are functioning properly. My newest server isn't using my normal stack, so I suspect I've configured it improperly. It is currently returning occasional 404 errors to the logging script.
Server Config
Ubuntu, Nginx, PostgreSQL, Supervisor;
Running a Docker container with Django/Wagtail and Gunicorn.
Looks fine when I visit in webbrowser, but my script logged four 404s in the last 12 hours.
My supervisor log shows the 404s but doesn't provide any additional useful information:
[2018-07-16 20:22:35 +0000] [9] [INFO] Booting worker with pid: 9
[2018-07-16 20:22:35 +0000] [10] [INFO] Booting worker with pid: 10
[2018-07-16 20:22:35 +0000] [11] [INFO] Booting worker with pid: 11
Not Found: /_server_health/
Not Found: /_server_health/
Not Found: /_server_health/
There is no relevant information captured in the Nginx log.
Can anyone recommend any steps I can take to gather further information? Or does this fit the pattern of any known problematic server configs?
Edit: It looks like Wagtail is sometimes causing the 404: "Raised by: wagtail.core.views.serve"
Maybe a problem in my urls.py? Should this be configured differently for Wagtail?
url(r'^_server_health$', status_api),
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.