So I've followed a few of the other questions however I can't upload files larger than 30 MB (trying to upload 250MB+)
payloadTooLargeError: request entity too large
I'm using AWS Elastic Beanstalk to run EC2 servers for me. Using MySQL databases.
My app.js file has this
const bodyParser = require('body-parser');
app.use(bodyParser.json({limit: '1500mb'}));
app.use(bodyParser.urlencoded({limit: '1500mb', extended: true}));
I added the following to
.platform/nginx/conf.d/upload_size.conf
proxy_buffers 4 12480M;
proxy_buffer_size 12480M;
proxy_busy_buffers_size 12480M;
client_body_buffer_size 12480M;
client_max_body_size 12480M;
Which did increase the filesize amount I could upload, but it seems anything larger than about 10 MB will display the following error in my Elastic Beanstalk log.
Jan 17 23:46:51 ip-172-31-43-187 web: at /var/app/current/app.js:181:47
Jan 17 23:46:51 ip-172-31-43-187 web: at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
Jan 17 23:46:51 ip-172-31-43-187 web: at next (/var/app/current/node_modules/express/lib/router/route.js:144:13)
Jan 17 23:46:51 ip-172-31-43-187 web: at Route.dispatch (/var/app/current/node_modules/express/lib/router/route.js:114:3)
Jan 17 23:46:51 ip-172-31-43-187 web: at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
Jan 17 23:46:51 ip-172-31-43-187 web: at /var/app/current/node_modules/express/lib/router/index.js:284:15
Jan 17 23:46:51 ip-172-31-43-187 web: at param (/var/app/current/node_modules/express/lib/router/index.js:365:14)
Jan 17 23:46:51 ip-172-31-43-187 web: at param (/var/app/current/node_modules/express/lib/router/index.js:376:14)
Jan 17 23:46:51 ip-172-31-43-187 web: at param (/var/app/current/node_modules/express/lib/router/index.js:376:14)
Jan 18 00:00:12 ip-172-31-43-187 web: PayloadTooLargeError: request entity too large
Jan 18 00:00:12 ip-172-31-43-187 web: at readStream (/var/app/current/node_modules/raw-body/index.js:156:17)
Jan 18 00:00:12 ip-172-31-43-187 web: at getRawBody (/var/app/current/node_modules/raw-body/index.js:109:12)
Jan 18 00:00:12 ip-172-31-43-187 web: at read (/var/app/current/node_modules/body-parser/lib/read.js:79:3)
Jan 18 00:00:12 ip-172-31-43-187 web: at jsonParser (/var/app/current/node_modules/body-parser/lib/types/json.js:135:5)
Jan 18 00:00:12 ip-172-31-43-187 web: at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
Jan 18 00:00:12 ip-172-31-43-187 web: at trim_prefix (/var/app/current/node_modules/express/lib/router/index.js:328:13)
Jan 18 00:00:12 ip-172-31-43-187 web: at /var/app/current/node_modules/express/lib/router/index.js:286:9
Jan 18 00:00:12 ip-172-31-43-187 web: at Function.process_params (/var/app/current/node_modules/express/lib/router/index.js:346:12)
Jan 18 00:00:12 ip-172-31-43-187 web: at next (/var/app/current/node_modules/express/lib/router/index.js:280:10)
Jan 18 00:00:12 ip-172-31-43-187 web: at expressInit (/var/app/current/node_modules/express/lib/middleware/init.js:40:5)
Jan 18 00:05:43 ip-172-31-43-187 web: PayloadTooLargeError: request entity too large
Jan 18 00:05:43 ip-172-31-43-187 web: at readStream (/var/app/current/node_modules/raw-body/index.js:156:17)
Jan 18 00:05:43 ip-172-31-43-187 web: at getRawBody (/var/app/current/node_modules/raw-body/index.js:109:12)
Jan 18 00:05:43 ip-172-31-43-187 web: at read (/var/app/current/node_modules/body-parser/lib/read.js:79:3)
Jan 18 00:05:43 ip-172-31-43-187 web: at jsonParser (/var/app/current/node_modules/body-parser/lib/types/json.js:135:5)
Jan 18 00:05:43 ip-172-31-43-187 web: at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
Jan 18 00:05:43 ip-172-31-43-187 web: at trim_prefix (/var/app/current/node_modules/express/lib/router/index.js:328:13)
Jan 18 00:05:43 ip-172-31-43-187 web: at /var/app/current/node_modules/express/lib/router/index.js:286:9
Jan 18 00:05:43 ip-172-31-43-187 web: at Function.process_params (/var/app/current/node_modules/express/lib/router/index.js:346:12)
Jan 18 00:05:43 ip-172-31-43-187 web: at next (/var/app/current/node_modules/express/lib/router/index.js:280:10)
Jan 18 00:05:43 ip-172-31-43-187 web: at expressInit (/var/app/current/node_modules/express/lib/middleware/init.js:40:5)
Jan 18 00:23:34 ip-172-31-43-187 web: TypeError: next is not a function
Anybody have any ideas on what it might be?
I have a feeling it's an AWS setting somewhere
Related
I'm trying to follow the tutorial, but facing the below error.
The error was disappeared when I changed the permissions of the parent folder and the db.sqlite3 file to 777, but that's not the good idea.
What's the alternative?
Reference:
https://docs.djangoproject.com/en/3.2/intro/tutorial02/
Error:
OperationalError at /admin/logout/
attempt to write a readonly database
Request Method: GET
Request URL: http://x.x.x.x/admin/logout/
Django Version: 3.1.6
Exception Type: OperationalError
Exception Value:
attempt to write a readonly database
Exception Location: /opt/bitnami/python/lib/python3.8/site-packages/django/db/backends/sqlite3/base.py, line 413, in execute
Python Executable: /usr/bin/python3
Python Version: 3.8.7
Python Path:
['/opt/bitnami/python/lib/python38.zip',
'/opt/bitnami/python/lib/python3.8',
'/opt/bitnami/python/lib/python3.8/lib-dynload',
'/opt/bitnami/python/lib/python3.8/site-packages',
'/opt/bitnami/python/lib/python3.8/site-packages/setuptools-46.4.0-py3.8.egg',
'/opt/bitnami/python/lib/python3.8/site-packages/pip-20.3.4-py3.8.egg',
'/opt/bitnami/python/lib/python3.8/site-packages/virtualenv-20.4.2-py3.8.egg',
'/opt/bitnami/python/lib/python3.8/site-packages/six-1.15.0-py3.8.egg',
'/opt/bitnami/python/lib/python3.8/site-packages/filelock-3.0.12-py3.8.egg',
'/opt/bitnami/python/lib/python3.8/site-packages/distlib-0.3.1-py3.8.egg',
'/opt/bitnami/python/lib/python3.8/site-packages/appdirs-1.4.4-py3.8.egg',
'/opt/bitnami/apps/django/django_projects/tutorial']
Server time: Thu, 29 Apr 2021 06:17:14 +0000
Folder and file status:
bitnami#ip---:/opt/bitnami/apps/django/django_projects$ ls -al
total 12
drwxrwxr-x 3 root root 4096 Apr 22 05:09 .
drwxr-xr-x 3 root root 4096 Apr 22 05:09 ..
drwxrwxr-x 6 www-data www-data 4096 Apr 29 06:16 tutorial
bitnami#ip---:/opt/bitnami/apps/django/django_projects$ ls -al tutorial/
total 168
drwxrwxr-x 6 www-data www-data 4096 Apr 29 06:16 .
drwxrwxr-x 3 root root 4096 Apr 22 05:09 ..
drwxr-xr-x 2 www-data www-data 4096 Apr 22 05:45 conf
-rwxrwxrwx 1 www-data www-data 143360 Apr 29 06:16 db.sqlite3
drwxr-xr-x 4 www-data www-data 4096 Apr 28 16:08 hello_world
-rwxr-xr-x 1 www-data www-data 664 Apr 22 05:08 manage.py
drwxr-xr-x 4 www-data www-data 4096 Apr 28 18:04 polls
drwxr-xr-x 3 www-data www-data 4096 Apr 28 16:12 tutorial
Updated the solution by myself :
$ sudo chown daemon:daemon /opt/bitnami/apps/django/django_projects
$ sudo chown daemon:daemon /opt/bitnami/apps/django/django_projects/db.sqlite3
$ sudo chmod 775 /opt/bitnami/apps/django/django_projects
$ sudo chown 775 /opt/bitnami/apps/django/django_projects/db.sqlite3
Platform : AWS Lightsail
Finally it works!
I am trying to deploy my Django website to a Ubuntu server. I am following this tutorial: linuxhint.com/create_django_app_ubuntu/. However, the Gunicorn service doesn't work.
I have my site at /home/django/blog.
My Python 3.6 virtualenv is activated at /home/django/.venv/bin/activate (-rwxr-xr-x 1 django root 2207 Sep 21 14:07 activate).
The script for starting the server is at /home/django/bin/start-server.sh (-rwxr-xr-x 1 django root 69 Sep 21 15:50 start-server.sh), with the following content:
cd /home/django
source .venv/bin/activate
cd blog
gunicorn blog.wsgi
Running this script manually works just fine.
The Gunicorn service is at /etc/systemd/system/gunicorn.service, with this content:
[Unit]
Description=Gunicorn
After=network.target
[Service]
Type=simple
User=django
ExecStart=/home/django/bin/start-server.sh
Restart=on-failure
[Install]
WantedBy=multi-user.target
Running systemctl status gunicorn.service gives this:
● gunicorn.service - Gunicorn
Loaded: loaded (/etc/systemd/system/gunicorn.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2020-09-21 16:15:17 UTC; 6s ago
Process: 1114 ExecStart=/home/django/bin/start-server.sh (code=exited, status=203/EXEC)
Main PID: 1114 (code=exited, status=203/EXEC)
Sep 21 16:15:17 example.com systemd[1]: gunicorn.service: Failed with result 'exit-code'.
Sep 21 16:15:17 example.com systemd[1]: gunicorn.service: Service hold-off time over, scheduling restart.
Sep 21 16:15:17 example.com systemd[1]: gunicorn.service: Scheduled restart job, restart counter is at 5.
Sep 21 16:15:17 example.com systemd[1]: Stopped Gunicorn.
Sep 21 16:15:17 example.com systemd[1]: gunicorn.service: Start request repeated too quickly.
Sep 21 16:15:17 example.com systemd[1]: gunicorn.service: Failed with result 'exit-code'.
Sep 21 16:15:17 example.com systemd[1]: Failed to start Gunicorn.
Sep 21 16:15:18 example.com systemd[1]: gunicorn.service: Start request repeated too quickly.
Sep 21 16:15:18 example.com systemd[1]: gunicorn.service: Failed with result 'exit-code'.
Sep 21 16:15:18 example.com systemd[1]: Failed to start Gunicorn.
Sep 21 14:22:36 example.com systemd[7906]: gunicorn.service: Failed to execute command: Permission denied
Sep 21 14:22:36 example.com systemd[7906]: gunicorn.service: Failed at step EXEC spawning /home/django/bin/start-server.sh: Permission denied
Sep 21 14:23:40 example.com systemd[7940]: gunicorn.service: Failed to execute command: Permission denied
Sep 21 14:23:40 example.com systemd[7940]: gunicorn.service: Failed at step EXEC spawning /home/django/bin/start-server.sh: Permission denied
Sep 21 14:24:47 example.com systemd[7958]: gunicorn.service: Failed to execute command: Permission denied
Sep 21 14:24:47 example.com systemd[7958]: gunicorn.service: Failed at step EXEC spawning /home/django/bin/start-server.sh: Permission denied
Permission denied
.
.
.
I ran chown -R django:django /home/django. Now, the output of ls -lah /home/django is:
total 32K
drwxr-xr-x 5 django django 4.0K Sep 21 14:19 .
drwxr-xr-x 3 root root 4.0K Sep 21 14:04 ..
-rw-r--r-- 1 django django 220 Apr 4 2018 .bash_logout
-rw-r--r-- 1 django django 3.7K Apr 4 2018 .bashrc
-rw-r--r-- 1 django django 807 Apr 4 2018 .profile
drwxr-xr-x 4 django django 4.0K Sep 21 14:07 .venv
drwxr-xr-x 2 django django 4.0K Sep 21 15:58 bin
drwxr-xr-x 3 django django 4.0K Sep 21 14:08 blog
Solution
Thanks to Dmitry Belaventsev, the solution to this is to change
ExecStart=/home/django/bin/start-server.sh
to
ExecStart=/bin/bash /home/django/bin/start-server.sh
In the file /etc/systemd/system/gunicorn.service.
Your systemd service is setup to execute the script from behalf of django user. In the meantime:
ls -lah /home/django
total 32K
drwxr-xr-x 5 django django 4.0K Sep 21 14:19 .
drwxr-xr-x 3 root root 4.0K Sep 21 14:04 ..
-rw-r--r-- 1 django django 220 Apr 4 2018 .bash_logout
-rw-r--r-- 1 django django 3.7K Apr 4 2018 .bashrc
-rw-r--r-- 1 django django 807 Apr 4 2018 .profile
drwxr-xr-x 4 django root 4.0K Sep 21 14:07 .venv
drwxr-xr-x 2 root root 4.0K Sep 21 15:58 bin
drwxr-xr-x 3 root root 4.0K Sep 21 14:08 blog
As you can see:
drwxr-xr-x 3 root root 4.0K Sep 21 14:04 ..
and
drwxr-xr-x 2 root root 4.0K Sep 21 15:58 bin
which means:
/home directory belongs to root:root
/home/django/bin belongs to root:root
To let systemd execute a bash script from behalf of django user:
That script should be executable
All parent directories should have execution rights
All those directories and the script should be available for django user
The quickest solution:
chown -R /home/django django:django
Also you could play with group and group rights as well.
I've some strange behavior on my production machines.
I'm running Python 2.7.12 on Ubuntu 16.04. Nginx as the web server (1.10.3). I'm running a Django (1.11.15) application. UWSGI 2.0.17.1 will handle requests to the application server.
Basically, everything runs fine. Until I reboot the machine. After rebooting it takes about 3 minutes before I see the message 'announcing my loyalty to the Emperor...'.
From the moment the system restarted until the UWSGI is ready, my Nginx received 499/502 and 503 error.
I tried a lot of things to fix this issue. One of the things I did is starting the machine without starting NGinx. Wait for 3 minutes, start NGinx and then everything runs fine. So, it seems like an issue with the Emperor/Systemd.
My emperor file:
[Unit]
Description=uWSGI Emperor service
After=syslog.target
[Service]
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
My uwsgi:
# d4t wsgi ini file
[uwsgi]
# master
master = false
# maximum number of processes
processes = 5
# threads
enable-threads = true
# socket to use
socket = /tmp/uwsgi-omniit.sock
# permissions
chmod-socket = 666
# base directory
chdir = /var/www/omni-it/omniit/
# virtualenv
virtualenv = /var/www/omni-it/
# module
module = omniit.wsgi:application
# buffer size: the autocomplete is a bit large in the request
buffer-size = 8190
# user and group
uid = www-data
gid = www-data
After rebooting, syslog output:
Aug 12 18:21:45 tst001app20 uwsgi[348]: WSGI app 0 (mountpoint='') ready in 5 seconds on interpreter 0x23486e0 pid: 366 (default app)
Aug 12 18:21:45 tst001app20 uwsgi[348]: *** uWSGI is running in multiple interpreter mode ***
Aug 12 18:21:45 tst001app20 uwsgi[348]: spawned uWSGI master process (pid: 366)
Aug 12 18:21:45 tst001app20 uwsgi[348]: Sun Aug 12 18:21:45 2018 - [emperor] vassal omniit_uwsgi.ini has been spawned
Aug 12 18:21:45 tst001app20 uwsgi[348]: spawned uWSGI worker 1 (pid: 757, cores: 1)
Aug 12 18:21:45 tst001app20 uwsgi[348]: spawned uWSGI worker 2 (pid: 758, cores: 1)
Aug 12 18:21:45 tst001app20 uwsgi[348]: spawned uWSGI worker 3 (pid: 759, cores: 1)
Aug 12 18:21:45 tst001app20 uwsgi[348]: spawned uWSGI worker 4 (pid: 760, cores: 1)
Aug 12 18:21:45 tst001app20 uwsgi[348]: spawned uWSGI worker 5 (pid: 761, cores: 1)
Aug 12 18:21:45 tst001app20 uwsgi[348]: Sun Aug 12 18:21:45 2018 - [emperor] vassal omniit_uwsgi.ini is ready to accept requests
Aug 12 18:21:45 tst001app20 ntpd[730]: Soliciting pool server 213.136.0.252
Aug 12 18:21:45 tst001app20 ntpd[730]: Soliciting pool server 85.255.214.66
Aug 12 18:21:45 tst001app20 ntpd[730]: Listen normally on 7 eth0 [fe80::35ff:fe33:1e%2]:123
Aug 12 18:21:45 tst001app20 ntpd[730]: new interface(s) found: waking up resolver
Aug 12 18:21:45 tst001app20 ntpd[730]: Soliciting pool server 213.109.127.82
Aug 12 18:21:45 tst001app20 ntpd[730]: receive: Unexpected origin timestamp from 83.162.177.33
Aug 12 18:21:45 tst001app20 systemd[1]: Time has been changed
Aug 12 18:21:45 tst001app20 systemd[1]: apt-daily.timer: Adding 27min 21.221010s random time.
Aug 12 18:21:46 tst001app20 ntpd[730]: Soliciting pool server 213.154.229.24
Aug 12 18:21:46 tst001app20 ntpd[730]: Soliciting pool server 13.80.10.154
Aug 12 18:21:46 tst001app20 ntpd[730]: Soliciting pool server 212.114.109.139
Aug 12 18:21:46 tst001app20 ntpd[730]: Soliciting pool server 149.210.199.182
Aug 12 18:22:48 tst001app20 kernel: [ 70.779037] random: nonblocking pool is initialized
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request / (ip 145.7.170.253) !!!
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request / (ip 145.7.170.254) !!!
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request / (ip 145.7.170.124) !!!
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request / (ip 145.7.170.124) !!!
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during GET / (145.7.170.254)
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request / (ip 145.7.170.254) !!!
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during GET / (145.7.170.254)
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during GET / (145.7.170.124)
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during GET / (145.7.170.124)
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 20:24:57 2018 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during GET / (145.7.170.253)
Aug 12 18:24:57 tst001app20 uwsgi[348]: IOError: write error
Aug 12 18:24:57 tst001app20 uwsgi[348]: [pid: 758|app: 0|req: 1/1] 145.7.170.254 () {38 vars in 451 bytes} [Sun Aug 12 20:22:35 2018] GET / => generated 0 bytes in 142151 msecs (HTTP/1.1 302) 8 headers in 0 bytes (0 switches on core 0)
Aug 12 18:24:57 tst001app20 uwsgi[348]: announcing my loyalty to the Emperor...
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 18:24:57 2018 - [emperor] vassal omniit_uwsgi.ini is now loyal
Aug 12 18:24:57 tst001app20 uwsgi[348]: IOErrorIOError: write error
Aug 12 18:24:57 tst001app20 uwsgi[348]: [pid: 757|app: 0|req: 1/2] 145.7.170.254 () {38 vars in 451 bytes} [Sun Aug 12 20:22:03 2018] GET / => generated 0 bytes in 174008 msecs (HTTP/1.1 302) 8 headers in 0 bytes (0 switches on core 0)
Aug 12 18:24:57 tst001app20 uwsgi[348]: : write error
Aug 12 18:24:57 tst001app20 uwsgi[348]: [pid: 759|app: 0|req: 1/3] 145.7.170.124 () {38 vars in 451 bytes} [Sun Aug 12 20:21:46 2018] GET / => generated 0 bytes in 191803 msecs (HTTP/1.1 302) 8 headers in 0 bytes (0 switches on core 0)
Aug 12 18:24:57 tst001app20 uwsgi[348]: announcing my loyalty to the Emperor...
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 18:24:57 2018 - [emperor] vassal omniit_uwsgi.ini is now loyal
Aug 12 18:24:57 tst001app20 uwsgi[348]: announcing my loyalty to the Emperor...
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 18:24:57 2018 - [emperor] vassal omniit_uwsgi.ini is now loyal
Aug 12 18:24:57 tst001app20 uwsgi[348]: IOError: write error
Aug 12 18:24:57 tst001app20 uwsgi[348]: [pid: 760|app: 0|req: 1/4] 145.7.170.253 () {38 vars in 451 bytes} [Sun Aug 12 20:23:50 2018] GET / => generated 0 bytes in 67595 msecs (HTTP/1.1 302) 8 headers in 0 bytes (0 switches on core 0)
Aug 12 18:24:57 tst001app20 uwsgi[348]: announcing my loyalty to the Emperor...
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 18:24:57 2018 - [emperor] vassal omniit_uwsgi.ini is now loyal
Aug 12 18:24:57 tst001app20 uwsgi[348]: IOError: write error
Aug 12 18:24:57 tst001app20 uwsgi[348]: [pid: 761|app: 0|req: 1/5] 145.7.170.124 () {38 vars in 451 bytes} [Sun Aug 12 20:22:16 2018] GET / => generated 0 bytes in 161628 msecs (HTTP/1.1 302) 8 headers in 0 bytes (0 switches on core 0)
Aug 12 18:24:57 tst001app20 uwsgi[348]: announcing my loyalty to the Emperor...
Aug 12 18:24:57 tst001app20 uwsgi[348]: Sun Aug 12 18:24:57 2018 - [emperor] vassal omniit_uwsgi.ini is now loyal
Aug 12 18:24:57 tst001app20 uwsgi[348]: [pid: 758|app: 0|req: 2/6] 145.7.170.254 () {38 vars in 451 bytes} [Sun Aug 12 20:24:57 2018] GET / => generated 0 bytes in 14 msecs (HTTP/1.1 302) 8 headers in 292 bytes (1 switches on core 0)
After this, I can just reload and restart the emperor without any problem. No errors occur anymore.
Any help would be appreciated!
When I am loading my class directly from some location I am able to load it.
>>> import sys
>>> sys.path.append('/path/to/my/flask/application')
>>> from myfile import app as application
>>>
Now from wsgi when I am doing the same thing.. it's not loading.
[Sat Aug 19 07:41:18 2017] [info] mod_wsgi (pid=29177): Imported 'mod_wsgi'.
[Sat Aug 19 07:41:24 2017] [error] [client 129.91.63.143] mod_wsgi (pid=29172): Target WSGI script '/var/www/flask-prod/webtool.wsgi' cannot be loaded as Python module.
[Sat Aug 19 07:41:24 2017] [error] [client 129.91.63.143] mod_wsgi (pid=29172): Exception occurred processing WSGI script '/var/www/flask-prod/webtool.wsgi'.
[Sat Aug 19 07:41:24 2017] [error] [client 129.91.63.143] Traceback (most recent call last):
[Sat Aug 19 07:41:24 2017] [error] [client 129.91.63.143] File "/var/www/flask-prod/webtool.wsgi", line 6, in <module>
[Sat Aug 19 07:41:24 2017] [error] [client 129.91.63.143] from myfile import app as application
[Sat Aug 19 07:41:24 2017] [error] [client 129.91.63.143] ImportError: No module named myfile
wsgi virtual host configuration below:
WSGIPythonHome /pathto/condadir
WSGIPythonPath /pathto/condadir/lib/python2.7
<virtualhost *:80>
ServerName myhost.example.com
WSGIDaemonProcess webtool user=apache group=root threads=5 home=/var/www/flask-prod/
WSGIScriptAlias / /var/www/flask-prod/webtool.wsgi
<directory /var/www/flask-prod>
WSGIApplicationGroup %{GLOBAL}
WSGIScriptReloading On
Order allow,deny
Allow from all
</directory>
</virtualhost>
Below is the wsgi file.
#!/pathto/condadir/bin/python
import sys
sys.path.append('/path/to/my/flask/application')
from myfile import app as application
Server mount status:
$ df -hP
/dev/xvda1 494M 29M 440M 7% /boot
tmpfs 5.0G 0 5.0G 0% /dev/shm
/dev/xvdc1 50G 3.2G 44G 7% /path
/dev/mapper/vg_apol-lv_var 1.5G 164M 1.3G 12% /var
My Application:
$ ls -lrt /path/to/my/flask/
-rwxrwx--- 1 root root 109 Aug 9 11:16 README
drwxrwx--- 4 root root 4096 Aug 19 08:24 application
-rw------- 1 root root 0 Aug 19 08:25 __init__.py
$ ls -lrt /path/to/my/flask/application
-rwxrwx--- 1 root root 23 Jun 4 05:19 __init__.py
drwxrwx--- 6 root root 4096 Aug 7 15:24 static
-rwxrwx--- 1 root root 7168 Aug 9 11:45 users_sqlite.db
-rwxrwx--- 1 root root 9670 Aug 9 12:06 myfile.py
drwxrwx--- 5 root root 4096 Aug 10 14:50 templates
-rwxrwx--- 1 root root 448 Aug 10 14:51 myfile.pyc
httpd app portion:
$ pwd
/var/www
$ ls -ld flask-prod
drwxr-xr-x 2 root root 4096 Aug 19 08:21 flask-prod
$ ls -rlt flask-prod/
total 28
-rw------- 1 root root 0 Aug 18 15:54 __init__.py
-rwxr-xr-x 1 root root 258 Aug 19 08:21 webtool.wsgi
I'm setting up a django, gunicorn and nginx and when I visit the homepage I get a 502 gateway error.
The logs shows it's related to the permissions of the sock file
2017/07/01 09:59:18 [crit] 12237#12237: *23 connect() to unix:/home/sammy/revamp/revamp/revamp.sock failed (13: Permission denied) while connecting to upstream, client: 105.49.30.134, server: $
And the permissions are
srwxrwxrwx 1 sammy www-data 0 Jul 1 05:29 revamp.sock
gunicorn service is setup like so
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/revamp
ExecStart=/home/sammy/revamp/revampenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/home/sammy/revamp/revamp.sock revamp.wsgi:application
[Install]
WantedBy=multi-user.target
the permissions look okay and systemctl status gunicorn is active.
UPDATE
The permissions for the folder are as follows
total 2128
drwxr-xr-x 3 sammy root 4096 Jun 28 05:21 account
-rw-r--r-- 1 sammy root 48 Jun 27 09:34 brain
-rw-r--r-- 1 sammy root 1037922 Jun 28 11:34 data.json
-rwxr-xr-x 1 sammy root 1087488 Jun 27 09:35 db.sqlite3
drwxr-xr-x 4 sammy root 4096 Jun 28 05:21 gallery
-rw-r--r-- 1 sammy root 1326 Jun 27 09:34 hip-hop.txt
-rwxr-xr-x 1 sammy root 0 Jun 27 09:34 lUhbv4PA5t.jpg
-rwxr-xr-x 1 sammy root 249 Jun 27 09:34 manage.py
-rwxr-xr-x 1 sammy root 473 Jun 27 09:34 names.txt
-rw-r--r-- 1 sammy root 211 Jun 27 09:34 nsfw
-rw-r--r-- 1 sammy root 417 Jun 27 09:34 obsene.txt
-rwxr-xr-x 1 sammy root 1803 Jun 27 09:34 phrases.txt
drwxr-xr-x 5 sammy root 4096 Jul 1 07:59 revamp
drwxrwxr-x 6 sammy sammy 4096 Jul 1 05:14 revampenv
srwxrwxrwx 1 sammy www-data 0 Jul 1 05:29 revamp.sock
-rw-r--r-- 1 sammy root 97 Jun 27 09:33 to do
Not only the file itself, but directories that lead to the file should be also accessible by the nginx process.
Check /home/sammy, /home/sammy/revamp directories' permissions.