Django nginx 500 internal server error

How To Fix – “HTTP 500 Server Error” When Setting DEBUG = False in Django on AzureAWS ?

How To Fix – “HTTP 500 Server Error” When Setting DEBUG = False in Django on AzureAWS ?

In this post, we will see How To Fix – “HTTP 500 Server Error” When Setting DEBUG = False in Django. How the error might look like in the terminal or application. You might also find this error when you upgrade your Django version and start working with the newer version.

Coming to the error, it so happens that when you use DEBUG=TRUE, you get no error. But when you set DEBUG=FALSE, you get the error.

Let’s do some primitive checks.

Primitive Checks :

• Is the error happening at all the urls routes (apps) of your site ?
• Is the admin url working ?
• Are all your Static files in place ?

Once you are done with the Primitive Checks, you can proceed ahead with the more specific checks.

Check 1:

Some static files might also cause this problem when Debug was set to False.

The server might not be able to find some of the static files.

If the statics are not collected, in such cases also this error might occur.

• Verify your Static configs in Settings.py file and cross-check if their values are correct.
  • STATIC_URL = ‘/static/’
  • STATICFILES_DIRS =
  • STATIC_ROOT

• Check your Static File configs in Settings.py. Try using below. Sometimes whitenoise is not able to find some static imagesfiles and throws ValueError. Try each of the below one by one and see if that solves the error. But use only one at a time for Setting.py.

• Do a collectstatic when you launch the server.

Check 2:

Have you used ALLOWED_HOSTS in Settings.py ?

ALLOWED_HOSTS is required in Production. This setting is MUST whenever you set DEBUG=False.

Because ALLOWED_HOSTS setting validates the request’s Host header and Safeguards against any kind of host-impacting attacks.

If you don’t use this , SuspiciousOperation is raised. That means when a user performs some operation, that is considered as suspicious from a security perspective e.g. tampering with a session cookie.

And if such a SuspiciousOperation exception reaches the WSGI handler level, then it is logged at the Error level.

Check 3:

Are you using the ADMINS in Settings.py ?

A list of all the people who get code error notifications.

Let’s see some interesting facts first.

First thing first, your Django app can actually send email to the users listed in the ADMINS setting whenever any an internal server error occurs (for HTTP status code of 500 or greater). That way, the ADMINS gets description of the error, complete Python traceback, details about the HTTP request that caused the error, the details of exceptions raised in the request/response cycle etc.

It is advisable to set this up by –

• Specifying EMAIL_HOST , EMAIL_HOST_USER and EMAIL_HOST_PASSWORD, SERVER_EMAIL
• Put the email addresses of the addressees in the ADMINS setting.
• Refer Django settings documentation for complete list of email settings.
• By default, Django will send email from [email protected] – modify the SERVER_EMAIL setting, for setting a different user.

Источник

Ошибка 500 internal server error Nginx

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 500 internal server error. Сначала она может испугать и ввести в заблуждение, поскольку обычно веб-сервер выдает более конкретные ошибки, в которых указана точная причина проблемы, например, превышено время ожидания, неверный запрос или файл не найден, а тут просто сказано что, обнаружена внутренняя ошибка.

Но не все так страшно и в большинстве случаев проблема вполне решаема и очень быстро. В этой статье мы разберем как исправить ошибку Internal server error в Nginx.

Как исправить 500 internal server error Nginx

Дословно Internal server error означает внутренняя ошибка сервера. И вызвать её могут несколько проблем. Вот основные из них:

• Ошибки в скрипте на PHP — одна из самых частых причин;
• Превышено время выполнения PHP скрипта или лимит памяти;
• Неправильные права на файлы сайта;
• Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

Мы привыкли к тому, что если в PHP скрипте есть ошибки, то сразу же видим их в браузере. Однако на производственных серверах отображение сообщений об ошибках в PHP отключено, чтобы предотвратить распространение информации о конфигурации сервера для посторонних. Nginx не может отобразить реальную причину ошибки, потому что не знает что за ошибка произошла, а поэтому выдает универсальное сообщение 500 internal server error.

Чтобы исправить эту ошибку, нужно сначала понять где именно проблема. Вы можете включить отображение ошибок в конфигурационном файле php изменив значение строки display_errors с off на on. Рассмотрим на примере Ubuntu и PHP 7.2:

sudo systemctl restart php-fpm

Затем обновите страницу и вы увидите сообщение об ошибке, из-за которого возникла проблема. Далее его можно исправить и отключить отображение ошибок, тогда все будет работать. Ещё можно посмотреть сообщения об ошибках PHP в логе ошибок Nginx. Обычно он находится по пути /var/log/nginx/error.log, но для виртуальных доменов может настраиваться отдельно. Например, смотрим последние 100 строк в логе:

tail -n 100 -f /var/log/nginx/error.log

Теперь аналогично, исправьте ошибку и страница будет загружаться нормально, без ошибки 500.

2. Превышено время выполнения или лимит памяти

Это продолжение предыдущего пункта, так тоже относится к ошибкам PHP, но так, как проблема встречается довольно часто я решил вынести её в отдельный пункт. В файле php.ini установлены ограничения на время выполнения скрипта и количество оперативной памяти, которую он может потребить. Если скрипт потребляет больше, интерпретатор PHP его убивает и возвращает сообщение об ошибке.

Также подобная ошибка может возникать, если на сервере закончилась свободная оперативная память.

Если же отображение ошибок отключено, мы получаем error 500. Обратите внимание, что если время ожидания было ограничено в конфигурационном файле Nginx, то вы получите ошибку 504, а не HTTP ERROR 500, так что проблема именно в php.ini.

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300
memory_limit 512M

Также проблема может быть вызвана превышением других лимитов установленных для скрипта php. Смотрите ошибки php, как описано в первом пункте. После внесения изменений в файл перезапустите php-fpm:

sudo systemctl restart php-fpm

3. Неверные права на файлы

Такая ошибка может возникать, если права на файлы, к которым обращается Nginx установлены на правильно. Сервисы Nginx и php-fpm должны быть запущены от имени одного и того же пользователя, а все файлы сайтов должны принадлежать этому же пользователю. Посмотреть от имени какого пользователя запущен Nginx можно командой:

nginx -T | grep user

Чтобы узнать от какого пользователя запущен php-fpm посмотрите содержимое конфигурационного файла используемого пула, например www.conf:

sudo vi /etc/php-fpm.d/www.conf

В моем случае это пользователь nginx. Теперь надо убедится, что файлы сайта, к которым вы пытаетесь обратиться принадлежат именно этому пользователю. Для этого используйте команду namei:

namei -l /var/www/site

Файлы сайта должны принадлежать пользователю, от имени которого запущены сервисы, а по пути к каталогу с файлами должен быть доступ на чтение для всех пользователей. Если файлы принадлежат не тому пользователю, то вы можете все очень просто исправить:

sudo chown nginx:nginx -R /var/www/site

Этой командой мы меняем владельца и группу всех файлов в папке на nginx:nginx. Добавить права на чтение для всех пользователей для каталога можно командой chmod. Например:

sudo chmod o+r /var/www/

Далее все должно работать. Также, проблемы с правами может вызывать SELinux. Настройте его правильно или отключите:

Выводы

В этой статье мы разобрали что делать если на вашем сайте встретилась ошибка 500 internal server error nginx. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

Похожие записи

Нет похожих записей.

Оцените статью

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

2 комментария к “Ошибка 500 internal server error Nginx”

Чушь.
1. header(«http/1.1 500 Internal Server Error») ;
И логи не помогут.
2. Если скрипт превышает лимиты, то, вероятнее всего, в коде что-то не так. Бесконечный цикл, например. С ним, кстати, и увеличение этих лимитов не спасёт.

статья однобока. проблема к nginx вряд ли имеет отношение, зря в заголовок вынесено название этого великолепного сервера. nginx может работать, и работает, в связке не только с PHP. а на PHP свет клином не сошёлся. если уж пишете о PHP то и выносите в заголовок PHP, а не nginx.

инициировать такую ошибку можно элементарно. например, отключаем сервис PostgreSQL и вуаля. Welcome home, dear!

Источник

How to Fix 500 Internal Server Error in NGINX

Sometimes NGINX server may give 500 Internal Server Error due to various reasons. In this article we will look at what does 500 Internal Server Error mean in NGINX and how to fix 500 Internal Server Error in NGINX.

What is 500 Internal Server Error in NGINX

NGINX gives 500 Internal Server Error when there is a server-side error that prevents NGINX from returning a proper response. It can be due to many different reasons such as faulty script, missing files referenced by code, inadequate file permissions, etc. NGINX is typically used as a reverse proxy server, so the most common reason for 500 Internal server is an error in one of its web servers like Apache that has encountered an issue and returned a 500 error response to NGINX, which is then returned to client browsers. There are various ways to fix internal server error in NGINX.

How to Fix 500 Internal Server Error in NGINX

Here are the steps to fix 500 Internal Server Error in NGINX on localhost, CPanel, PHP, Ubuntu and other platforms.

1. Hard Refresh

Sometimes you may get 500 internal server error in NGINX because your server is being restarted at that moment, or there are too many requests for web server to handle.

So it doesn’t have enough resources to serve your request.

In such cases, you can simply do a hard refresh of your page to force the browser to get latest web page version and fix 500 internal server error in NGINX. You can do this by pressing

• Windows: Ctrl + F5
• Mac: Apple + R or Cmd + R
• Linux: F5

2. Examine Server Logs

Open your server log in a text editor to analyze the most recent requests. Every server log contains information about requested URLs and response code for each request.

Find out which requests result in 500 internal server error. It may be that only one page, or a few pages give this error while others work fine.

Find out which requests cause 500 internal server error. Once you have identified the problematic URLs, open a browser and request them again to confirm that is indeed the case.

3. Examine Your Script

Next, analyze the script to process the problematic requests. Is it actually present at the right location? Are you referencing it properly, in your URL mapping/routing file?

If your script refers to another file, find out if that file path is correct. If you have referenced any program/function, have you called it correctly?

4. Check File/Folder Permission

This can also be due to improper file/folder permissions. Did you add/modify any file/folder recently?

Typically, files need a 644 permission and folders need a 755 permission. You can use FileZilla (Windows) and Chmod (Linux) to modify file permissions.

You can also look at the permissions of other files & folders in your code and update the same for your files/folders accordingly.

5. Check redirections

If you have incorrectly setup any redirections in web server, it can give 500 internal server error. For example, if you use Apache web server, make sure you have properly configured mod_rewrite module and .htaccess file.

Also use a third-party tool to check the syntax of redirection/URL rewrite rules in your server configuration file.

6. Increase Script Timeout

You may also get 500 internal server error in NGINX if your web server (e.g Apache) is timing out on the request. In such cases, increase your web server (not NGINX) timeout value so that it stays connected to NGINX longer, and returns a proper response.

Hopefully, the above tips will help you fix 500 internal server error in NGINX.

Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!

Источник

🌐 Как исправить распространенные ошибки веб-сервера Nginx

Nginx – очень популярный веб-сервер в наши дни.

В этой статье мы расскажем вам о некоторых распространенных ошибках при работе веб-сервера Nginx и возможных решениях.

Это не полный список.

Если вы все еще не можете устранить ошибку, попробовав предложенные решения, пожалуйста, проверьте логи сервера Nginx в каталоге /var/log/nginx/ и поищите в Google, чтобы отладить проблему.

Unable to connect/Refused to Connect

Если при попытке получить доступ к вашему сайту вы видите следующую ошибку:

Это может быть потому, что:

• Nginx не запущен. Вы можете проверить состояние Nginx с помощью sudo systemctl status nginx. Запустите Nginx с помощью sudo systemctl start nginx. Если Nginx не удается запустить, запустите sudo nginx -t, чтобы выяснить, нет ли ошибок в вашем конфигурационном файле. И проверьте логи (sudo journalctl -eu nginx), чтобы выяснить, почему он не запускается.
• Брандмауэр блокирует порты 80 и 443. Если вы используете брандмауэр UFW на Debian/Ubuntu, выполните sudo ufw allow 80,443/tcp, чтобы открыть TCP порты 80 и 443. Если вы используете Firewalld на RHEL/CentOS/Rocky Linux/AlmaLinux, выполните sudo firewall-cmd –permanent –add-service=, затем sudo systemctl reload firewalld, чтобы открыть TCP порты 80 и 443.
• Fail2ban. Если ваш сервер использует fail2ban для блокировки вредоносных запросов, возможно, fail2ban запретил ваш IP-адрес. Выполните команду sudo journalctl -eu fail2ban, чтобы проверить, не заблокирован ли ваш IP-адрес. Вы можете добавить свой IP-адрес в список fail2ban ignoreip, чтобы он больше не был забанен.
• Nginx не прослушивает нужный сетевой интерфейс. Например, Nginx не прослушивает публичный IP-адрес сервера.

The Connection Has Timed Out

Это может означать, что ваш сервер находится в автономном режиме или Nginx работает неправильно.

Однажды у меня возникла проблема нехватки памяти, из-за чего Nginx не смог запустить рабочие процессы.

Если вы увидите следующее сообщение об ошибке в файле /var/log/nginx/error.log, вашему серверу не хватает памяти:

404 Not Found

404 not found означает, что Nginx не может найти ресурсы, которые запрашивает ваш веб-браузер.

Причина может быть следующей:

• Корневой каталог web не существует на вашем сервере. В Nginx корневой веб-каталог настраивается с помощью директивы root, например, так: root /usr/share/nginx/linuxbabe.com/;. Убедитесь, что файлы вашего сайта (HTML, CSS, JavaScript, PHP) хранятся в правильном каталоге.
• PHP-FPM не запущен. Вы можете проверить статус PHP-FPM с помощью sudo systemctl status php7.4-fpm (Debian/Ubuntu) или sudo systemctl status php-fpm.
• Вы забыли включить директиву try_files $uri /index.php$is_args$args; в конфигурационный файл сервера Nginx. Эта директива необходима для обработки PHP-кода.
• На вашем сервере нет свободного дискового пространства. Попробуйте освободить немного дискового пространства. Вы можете использовать утилиту ncdu (sudo apt install ncdu или sudo dnf install ncdu), чтобы узнать, какие каталоги занимают огромное количество дискового пространства.

403 Forbidden

Эта ошибка означает, что вам не разрешен доступ к ресурсам запроса.

Возможный сценарий включает:

• Администратор сайта блокирует публичный доступ к запрашиваемым ресурсам с помощью белого списка IP-адресов или других методов.
• На сайте может использоваться брандмауэр веб-приложения, например ModSecurity, который обнаружил атаку вторжения, поэтому заблокировал запрос.
  Некоторые веб-приложения могут показывать другое сообщение об ошибке, когда происходит запрет 403. Оно может сказать вам, что “secure connection failed, хотя причина та же.

500 Internal Server Error

Это означает, что в веб-приложении произошла какая-то ошибка.

Это может быть следующее

• Сервер базы данных не работает. Проверьте состояние MySQL/MariaDB с помощью sudo systemctl status mysql. Запустите его с помощью sudo systemctl start mysql. Запустите sudo journalctl -eu mysql, чтобы выяснить, почему он не запускается. Процесс MySQL/MariaDB может быть завершен из-за проблем с нехваткой памяти.
• Вы не настроили Nginx на использование PHP-FPM, поэтому Nginx не знает, как выполнять PHP-код.
• Если ваше веб-приложение имеет встроенный кэш, вы можете попробовать очистить кэш приложения, чтобы исправить эту ошибку.
• Ваше веб-приложение может создавать свой собственный журнал ошибок. Проверьте этот файл журнала, чтобы отладить эту ошибку.
• Возможно, в вашем веб-приложении есть режим отладки. Включите его, и вы увидите более подробные сообщения об ошибках на веб-странице. Например, вы можете включить режим отладки в почтовом сервере хостинг-платформы Modoboa, установив DEBUG = True в файле /srv/modoboa/instance/instance/settings.py.
• PHP-FPM может быть перегружен. Проверьте журнал PHP-FPM (например, /var/log/php7.4-fpm.log). Если вы обнаружили предупреждение [pool www] seems busy (возможно, вам нужно увеличить pm.start_servers, или pm.min/max_spare_servers), вам нужно выделить больше ресурсов для PHP-FPM.
• Иногда перезагрузка PHP-FPM (sudo systemctl reload php7.4-fpm) может исправить ошибку.

Nginx показывает страницу по умолчанию

Если вы пытаетесь настроить виртуальный хост Nginx и при вводе доменного имени в веб-браузере отображается страница Nginx по умолчанию, это может быть следующее

• Вы не использовали реальное доменное имя для директивы server_name в виртуальном хосте Nginx.
• Вы забыли перезагрузить Nginx.

504 Gateway time-out

Это означает, что апстрим, такой как PHP-FPM/MySQL/MariaDB, не может обработать запрос достаточно быстро.

Вы можете попробовать перезапустить PHP-FPM, чтобы временно исправить ошибку, но лучше начать настраивать PHP-FPM/MySQL/MariaDB для более быстрой работы.

Вот конфигурация InnoDB в моем файле /etc/mysql/mariadb.conf.d/50-server.cnf.

Это очень простая настройка производительности.

• InnoDB buffer pool size должен быть не менее половины вашей оперативной памяти. (Для VPS с небольшим объемом оперативной памяти я рекомендую установить размер буферного пула на меньшее значение, например 400M, иначе ваш VPS будет работать без оперативной памяти).
• InnoDB log file size должен составлять 25% от размера буферного пула.
• Установите потоки ввода-вывода для чтения и записи на максимум (64).
• Заставьте MariaDB использовать 3 экземпляра буферного пула InnoDB. Количество экземпляров должно соответствовать количеству ядер процессора в вашей системе.
• После сохранения изменений перезапустите MariaDB.

После сохранения изменений перезапустите MariaDB.

Вы также можете установить более длительное значение тайм-аута в Nginx, чтобы уменьшить вероятность тайм-аута шлюза.

Отредактируйте файл виртуального хоста Nginx и добавьте следующие строки в блок server <…>.

Если вы используете Nginx с PHP-FPM, то установите для параметра fastcgi_read_timeout большее значение, например 300 секунд.

По умолчанию это 60 секунд.

Затем перезагрузите Nginx.

PHP-FPM также имеет максимальное время выполнения для каждого скрипта.

Отредактируйте файл php.ini.

Вы можете увеличить это значение до 300 секунд.

Затем перезапустите PHP-FPM

Размер памяти исчерпан

Если вы видите следующую строку в журнале ошибок Nginx, это означает, что PHP достиг лимита памяти в 128 МБ.

Вы можете отредактировать файл php.ini (/etc/php/7.4/fpm/php.ini) и увеличить лимит памяти PHP.

Затем перезапустите PHP7.4-FPM.

Если ошибка все еще существует, скорее всего, в вашем веб-приложении плохой PHP-код, который потребляет много оперативной памяти.

PR_END_OF_FILE_ERROR

1. Вы настроили Nginx на перенаправление HTTP-запросов на HTTPS, но в Nginx нет блока сервера, обслуживающего HTTPS-запросы.
2. Может быть, Nginx не запущен?
3. Иногда основной бинарник Nginx запущен, но рабочий процесс может не работать и завершиться по разным причинам. Для отладки проверьте логи ошибок Nginx (/var/log/nginx/error.log).

Resource temporarily unavailable

Некоторые пользователи могут найти следующую ошибку в файле логов ошибок Nginx (в разделе /var/log/nginx/).

Обычно это означает, что на вашем сайте много посетителей и PHP-FPM не справляется с обработкой огромного количества запросов.

Вы можете изменить количество дочерних процессов PHP-FPM, чтобы он мог обрабатывать больше запросов.

Отредактируйте файл PHP-FPM www.conf.

(Путь к файлу зависит от дистрибутива Linux).

По умолчанию конфигурация дочернего процесса выглядит следующим образом:

Приведенная выше конфигурация означает.

• PHP-FPM динамически создает дочерние процессы. Нет фиксированного количества дочерних процессов.
• Создается не более 5 дочерних процессов.
• При запуске PHP-FPM запускаются 2 дочерних процесса.
• Есть как минимум 1 незанятый процесс.
• Максимум 3 неработающих процесса.

Убедитесь, что у вас достаточно оперативной памяти для запуска дополнительных дочерних процессов.

Сохраните и закройте файл.

Затем перезапустите PHP-FPM. (Возможно, вам потребуется изменить номер версии).

Чтобы следить за состоянием PHP-FPM, вы можете включить страницу status .

Найдите следующую строку в файле PHP-FPM www.conf.

Обратите внимание, что

Уберите точку с запятой, чтобы включить страницу состояния PHP-FPM.

Затем перезапустите PHP-FPM.

Затем отредактируйте файл виртуального хоста Nginx.

Добавьте следующие строки.

Директивы allow и deny используются для ограничения доступа.

Только IP-адреса из “белого списка” могут получить доступ к странице состояния.

Сохраните и закройте файл. Затем протестируйте конфигурацию Nginx.

Если проверка прошла успешно, перезагрузите Nginx, чтобы изменения вступили в силу.

В файле PHP-FPM www.conf дается хорошее объяснение того, что означает каждый параметр.

Если PHP-FPM очень занят и не может обслужить запрос немедленно, он поставит его в очередь.

По умолчанию может быть не более 511 ожидающих запросов, определяемых параметром listen.backlog.

Если вы видите следующее значение на странице состояния PHP-FPM, это означает, что в очереди еще не было ни одного запроса, т.е. ваш PHP-FPM может быстро обрабатывать запросы.

Если в очереди 511 ожидающих запросов, это означает, что ваш PHP-FPM очень загружен, поэтому вам следует увеличить количество дочерних процессов.

Вам также может понадобиться изменить параметр ядра Linux net.core.somaxconn, который определяет максимальное количество соединений, разрешенных к файлу сокетов в Linux, например, к файлу сокетов PHP-FPM Unix.

По умолчанию его значение равно 128 до ядра 5.4 и 4096 начиная с ядра 5.4.

Если у вас сайт с высокой посещаемостью, вы можете использовать большое значение.

Отредактируйте файл /etc/sysctl.conf.

Добавьте следующие две строки.

Сохраните и закройте файл. Затем примените настройки.

Примечание: Если ваш сервер имеет достаточно оперативной памяти, вы можете выделить фиксированное количество дочерних процессов для PHP-FPM, как показано ниже.

Два файла виртуального хоста для одного и того же сайта

Если вы запустите sudo nginx -t и увидите следующее предупреждение.

Это означает, что есть два файла виртуальных хостов, содержащих одну и ту же конфигурацию server_name.

Не создавайте два файла виртуальных хостов для одного сайта.

PHP-FPM Connection reset by peer

В файле логов ошибок Nginx отображается следующее сообщение.

Это может быть вызвано перезапуском PHP-FPM.

Если он перезапущен вручную самостоятельно, то вы можете игнорировать эту ошибку.

Утечки сокетов Nginx

Если вы обнаружили следующее сообщение об ошибке в файле /var/log/nginx/error.log, значит, у вашего Nginx проблема с утечкой сокетов.

Вы можете перезапустить ОС, чтобы решить эту проблему.

Если это не помогает, вам нужно скомпилировать отладочную версию Nginx, которая покажет вам отладочную информацию в логах.

Заключение

Надеюсь, эта статья помогла вам исправить распространенные ошибки веб-сервера Nginx.

Источник

I created a simple django app for user authentication, then I want to deploy on nginx with gunicorn. I create my custom user model with 2 fields: username, password.I have tested using:

python manange.py runserver 0.0.0.0:8000

It runs fine! But when I try to deploy on nginx with gunicorn, I got 500 internal server error. The command I used to test django with gunicorn is:

gunicorn --bind 127.0.0.1:8080 backend.wsgi:application

backend is my startapp. Here is my nginx config:

server {
    listen 8000;
    server_name localhost;
    location / {
        include proxy_params;
        proxy_pass http://127.0.0.1:8080;
    }
}

When I login from client site, it will send a post request with user’s credentials to the server. At the server side, it successfully receive the request with correct credentials, but when it tries to authenticate the user by querying the User table:

User.objects.get(username=username, password=password)

It gets exception:

(1054, "Unknown column 'auth_user.last_login' in 'field list'")

Uhm strange!!!! Where does the last_login column come from? Then, I checked my log and found something weird when I run django app with gunicorn and without gunicorn.

When running with without nginx and gunicorn, here is the log when it queries User table:

2016-06-25 10:38:11,815|DEBUG|(0.001) SELECT `auth_user`.`id`, `auth_user`.`username`, `auth_user`.`password`, `auth_user`.`role` FROM `auth_user` LIMIT 21; args=()

When running with nginx and gunicorn:

2016-06-25 10:33:57,983|DEBUG|(0.000) SELECT `auth_user`.`id`, `auth_user`.`password`, `auth_user`.`last_login`, `auth_user`.`is_superuser`, `auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`, `auth_user`.`email`, `auth_user`.`is_staff`, `auth_user`.`is_active`, `auth_user`.`date_joined` FROM `auth_user` LIMIT 21; args=()

It seems that when running with nginx and gunicorn, it’s not using my custom models. Anyone has any idea about this issue? Did I make any mistake when config nginx and gunicorn?

Hey there,

i installed etesync on a debian vps with these tutorials in combination:

• https://simonvandevelde.be/Guides/html/Tutorials/etesync.html#etesync-server
• https://github.com/etesync/server
• https://github.com/etesync/server/wiki/Production-setup-using-uWSGI-and-Nginx

When i am opening my browser and go to https://etesync.mydomain.de/admin/ i can see my django admin backend. When i am trying to login i get the error «Server Error (500)». I am not that used to django or virtualenv so i am really struggeling finding the error… Do someone have an idea?

I attached my config files.
etesync_nginx.conf.txt
uwsgi.ini.txt
etesync-server.ini.txt

Thanks for your help!
Lukas

My Steps are these:
1.

• sudo apt-get update && sudo apt-get upgrade
• sudo ufw allow 8000
• sudo ufw allow 8001

• sudo apt-get install python3-pip git
• pip3 install virtualenv

or

• apt-get install python3-virtualenv

• cd /home/luke
• git clone https://github.com/etesync/server-skeleton.git
• cd server-skeleton

• virtualenv -p python3 venv
• source venv/bin/activate

• pip3 install -r requirements.txt

• cp etesync-server.ini.example etesync-server.ini

• nano etesync-server.ini

edit to:

[global]
secret_file = secret.txt
debug = false

[allowed_hosts]
allowed_host1 = *

[database]
engine = django.db.backends.sqlite3
name = db.sqlite3

• ./manage.py migrate
• ./manage.py runserver 0.0.0.0:8000

Reachable under: http://etesync.mydomain.de:8000/
und: http://94.130.226.255:8000/

stop debug server with control+c

• apt-get install build-essential python3-dev
• sudo pip3 install wheel

• sudo pip3 install uwsgi

1. testing:

• cd /home/luke/server-skeleton/
• source venv/bin/activate
• uwsgi —http :8000 —module etesync_server.wsgi —virtualenv venv

stop with control+c

• sudo -s
• cd /home/luke/server-skeleton/
• source venv/bin/activate

• ./manage.py collectstatic

• nano etesync_nginx.conf

Edit:

upstream django {
    # server unix:///tmp/etesync_server.sock; # for a file socket
    server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

server {
    # the port your site will be served on
    listen      8000;
    # the domain name it will serve for
    server_name etesync.mydomain.de; # substitute your machine's IP address or domain name
    charset     utf-8;

    # max upload size
    client_max_body_size 75M;   # adjust to taste

    location /static {
        alias /home/luke/server-skeleton/static; # Project's static files
    }

    # Finally, send all non-media requests to the Django server.
    location / {
        uwsgi_pass  django;
        include     /etc/nginx/uwsgi_params; # the uwsgi_params file, this path by default
    }
}

• sudo cp etesync_nginx.conf /etc/nginx/sites-available/

• sudo ln -s /etc/nginx/sites-available/etesync_nginx.conf /etc/nginx/sites-enabled/etesync_nginx.conf

• systemctl restart nginx

• uwsgi —socket :8001 —module etesync_server.wsgi

• (wokring: uwsgi —http :8001 —module etesync_server.wsgi —virtualenv venv)

• sudo nano /etc/nginx/sites-available/etesync_nginx.conf

Edit:

upstream django {
    server unix:///tmp/etesync_server.sock; # for a file socket
    # server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

• sudo nano uwsgi.ini

Edit:

[uwsgi]
chdir = /home/luke/server-skeleton/
socket = /tmp/etesync_server.sock
chown-socket = luke:www-data
chmod-socket = 660
module = etesync_server.wsgi
master = true
uid = luke
virtualenv = venv

• (venv) luke@meeting:~/server-skeleton$ sudo uwsgi —ini uwsgi.ini

• sudo nano /etc/systemd/system/etesync_server.service

Edit:

[Unit]
Description=Execute the etesync server.

[Service]
ExecStart=/usr/local/bin/uwsgi --ini /home/luke/server-skeleton/uwsgi.ini

[Install]
WantedBy=multi-user.target

• sudo apt install policykit-1
• systemctl start etesync_server
• systemctl enable etesync_server

• sudo certbot —nginx

• cd /home/luke/server-skeleton/
• source venv/bin/activate
• ./manage.py createsuperuser

1. Django Backend has no css… repairing:

• root@meeting:/home/luke/server-skeleton# nano etesync-server.ini

Edit:
static_root = /home/luke/server-skeleton/static

• (venv) root@meeting:/home/luke/server-skeleton# ./manage.py collectstatic

1. server 500 error?

Sometimes NGINX server may give 500 Internal Server Error due to various reasons. In this article we will look at what does 500 Internal Server Error mean in NGINX and how to fix 500 Internal Server Error in NGINX.

NGINX gives 500 Internal Server Error when there is a server-side error that prevents NGINX from returning a proper response. It can be due to many different reasons such as faulty script, missing files referenced by code, inadequate file permissions, etc. NGINX is typically used as a reverse proxy server, so the most common reason for 500 Internal server is an error in one of its web servers like Apache that has encountered an issue and returned a 500 error response to NGINX, which is then returned to client browsers. There are various ways to fix internal server error in NGINX.

Bonus Read : How To Fix 504 Gateway Timeout Error in NGINX

How to Fix 500 Internal Server Error in NGINX

Here are the steps to fix 500 Internal Server Error in NGINX on localhost, CPanel, PHP, Ubuntu and other platforms.

1. Hard Refresh

Sometimes you may get 500 internal server error in NGINX because your server is being restarted at that moment, or there are too many requests for web server to handle.

So it doesn’t have enough resources to serve your request.

In such cases, you can simply do a hard refresh of your page to force the browser to get latest web page version and fix 500 internal server error in NGINX. You can do this by pressing

• Windows: Ctrl + F5
• Mac: Apple + R or Cmd + R
• Linux: F5

Bonus Read : How to Fix 502 Bad Gateway Error in NGINX

2. Examine Server Logs

Open your server log in a text editor to analyze the most recent requests. Every server log contains information about requested URLs and response code for each request.

Find out which requests result in 500 internal server error. It may be that only one page, or a few pages give this error while others work fine.

Find out which requests cause 500 internal server error. Once you have identified the problematic URLs, open a browser and request them again to confirm that is indeed the case.

Bonus Read : How to Increase Request Timeout in NGINX

3. Examine Your Script

Next, analyze the script to process the problematic requests. Is it actually present at the right location? Are you referencing it properly, in your URL mapping/routing file?

If your script refers to another file, find out if that file path is correct. If you have referenced any program/function, have you called it correctly?

4. Check File/Folder Permission

This can also be due to improper file/folder permissions. Did you add/modify any file/folder recently?

Typically, files need a 644 permission and folders need a 755 permission. You can use FileZilla (Windows) and Chmod (Linux) to modify file permissions.

You can also look at the permissions of other files & folders in your code and update the same for your files/folders accordingly.

Bonus Read : How to Increase File Upload Size in NGINX

5. Check redirections

If you have incorrectly setup any redirections in web server, it can give 500 internal server error. For example, if you use Apache web server, make sure you have properly configured mod_rewrite module and .htaccess file.

Also use a third-party tool to check the syntax of redirection/URL rewrite rules in your server configuration file.

6. Increase Script Timeout

You may also get 500 internal server error in NGINX if your web server (e.g Apache) is timing out on the request. In such cases, increase your web server (not NGINX) timeout value so that it stays connected to NGINX longer, and returns a proper response.

Hopefully, the above tips will help you fix 500 internal server error in NGINX.

Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!

I have a problem with my current setup… And the issue is, that if i set DEBUG = False in django settings.py file nginx stops showing django tracebacks on 500 errors, but does not show our 500 page either. It just displays nginx 502 bad gateway error.

I do get the email error with traceback, just as i’ve configured it to mail tracebacks to me, when they occur. But i want to display nice 500 page to users not nginx 502 gateway error…

Honestly, i dont even know where to begin searching the root of the problem. Im prepared to post all necessary config files, if some nginx expert would come and tell me what he wants to see.

alan

Edit1: I looked up what log file shows at one of those 500 errors, and it shows this:

[pid: 16203|app: 0|req: 1/1] my.ip.address () {46 vars in 915 bytes} [Thu Sep 12 10:01:17 2013] GET /settings/personal/ => generated 0 bytes in 1249 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)

Does this mean that its somehow django fault cause it looks like django returned 0 bytes?