Ich verfolge dies, um eine flask app (simple hello world) auf dem Ubuntu 16-04 bereitzustellen. Digital Ocean Tutorial
Alles funktioniert gut bis Testen von uWSGI Serving . Danach folgte ich dem beschriebenen Schritt und als ich endlich unten ankam und die IP-Adresse des Servers überprüfte, bekam ich:
502 Bad Gateway
Ok gut Ich habe mein Fehlerprotokoll durchsucht und überprüft. Ich habe Folgendes erhalten:
2017/01/16 05:29:27 [crit] 20714#20714: *2 connect() to unix:/home/sajjan/project/project.sock failed (2: No such file or directory) while connecting to upstream, client: xx.9.xxx.xxx, server: 138.xxx.xx.xxx, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/home/sajjan/project/project.sock:", Host: "xx.xx.xx.xx"
Nachdem ich ein Fehlerprotokoll erstellt habe, habe ich die Datei project.sock manuell erstellt. Gehe nochmal zur Server IP Adresse und dann gleicher Fehler "502 Bad Gateway"
Wieder das Fehlerprotokoll überprüft und dies festgestellt
2017/01/16 06:07:11 [crit] 20874#20874: *1 connect() to unix:/home/sajjan/project/project.sock failed (13: Permission denied) while connecting to upstream, client: 47.9.237.113, server: XX.XX.XX.XX, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/home/sajjan/project/project.sock:", Host: " XX.XX.XX.XX "
Ich habe das Berechtigungsproblem herausgefunden und die Berechtigung mit dem folgenden Befehl geändert
Sudo chmod 666 project.sock
Jetzt habe ich die Berechtigung überprüft (mit ls -l Dateiname)
-rw-rw-rw- 1 root root 0 Jan 16 05:31 project.sock
Jetzt gehe ich zurück, um die IP des Servers zu überprüfen, stelle aber dasselbe "502 Bad Gateway" fest. Wieder habe ich das Fehlerprotokoll überprüft und Folgendes festgestellt:
017/01/16 06:13:31 [error] 20897#20897: *6 connect() to unix:/home/sajjan/project/project.sock failed (111: Connection refused) while connecting to upstream, client: 47.9.237.113, server: XX.XX.XX.XX, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:/home/sajjan/project/project.sock:", Host: " XX.XX.XX.XX ", referrer: "http:// XX.XX.XX.XX /"
Ich habe in den letzten zwei Tagen viel nach oben gegoogelt, aber nichts scheint für mich zu funktionieren. Ich habe diese Antworten überprüft, aber keine Hilfe stackanswer-1stackanswer-2 und zusammen mit diesen habe ich den gesamten Thread der Digital-Ocean-Community überprüft, aber nichts scheint zu funktionieren.
Ich bin ein absoluter Server-Anfänger und weiß nicht viel über Ubuntu. Wenn Sie mir helfen können, herauszufinden, was ich falsch mache, oder mir ein besseres Tutorial/Möglichkeiten zum Bereitstellen meiner Kolbenanwendung vorschlagen, wäre ich sehr dankbar.
Das sind meine Dateien
hallo.py
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "<h1 style='color:blue'>Hello There!</h1>"
if __== "__main__":
app.run(Host='0.0.0.0')
project.ini
[uwsgi]
module = wsgi:app
master = true
processes = 5
socket = /home/sajjan/project/project.sock
chmod-socket = 660
vacuum = true
die-on-term = true
wsgi.py
from hello import app
if __== "__main__":
app.run()
Unten ist die Datei:/etc/nginx/sites-available/project
server {
listen 80;
server_name 138.197.28.107;
location / {
include uwsgi_params;
uwsgi_pass unix:/home/sajjan/project/project.sock;
}
}
Wenn ich den Befehl ausführe:
Sudo service uwsgi restart
ausgabe:
Failed to restart wsgi.service: Unit wsgi.service not found.
während der Ausgabe von
Sudo service nginx status/restart
dann zeigt dies, dass nginx läuft.
Helfen Sie mir, wenn Sie noch etwas wissen wollen, lassen Sie es mich wissen. Vielen Dank
BEARBEITEN:
Ich habe eine project.service-Datei erstellt und ihr Inhalt ist:
[Unit]
Description=uWSGI instance to serve project
After=network.target
[Service]
User=sajjan
Group=www-data
WorkingDirectory=/home/sajjan/project
Environment="PATH=/home/sajjan/project/venv/bin"
ExecStart=/home/sajjan/project/venv/bin/uwsgi --ini project.ini
[Install]
WantedBy=multi-user.target
Ich habe herausgefunden, dass ich den folgenden Befehl ausführen muss:
Sudo systemctl start project
Ausgabe ist:
Warning: project.service changed on disk. Run 'systemctl daemon-reload' to reload units.
und wenn ich renne
Sudo systemcl reload project
dann ausgeben:
Failed to reload project.service: Job type reload is not applicable for unit project.service.
See system logs and 'systemctl status project.service' for details.
und wenn ich den "systemctl status project.service" überprüfe
● project.service - uWSGI instance to serve project
Loaded: loaded (/etc/systemd/system/project.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2017-01-16 17:49:29 UTC; 6min ago
Main PID: 27157 (code=exited, status=203/EXEC)
Jan 16 17:49:29 learningwithpython systemd[1]: Started uWSGI instance to serve project.
Jan 16 17:49:29 learningwithpython systemd[1]: project.service: Main process exited, code=exited, status=203/EXEC
Jan 16 17:49:29 learningwithpython systemd[1]: project.service: Unit entered failed state.
Jan 16 17:49:29 learningwithpython systemd[1]: project.service: Failed with result 'exit-code'.
Ich hatte das gleiche Problem mit der Anleitung. Soweit ich gelesen habe; 502 Bad Gateway ist ein Symptom dafür, dass Nginx keine ordnungsgemäße Verbindung zum UWSGI herstellen kann. Das Ändern der Berechtigungen für den Socket löste das Problem für mich.
Sudo chmod 777 /home/sajjan/project/project.sock
Sudo systemctl restart nginx
777 ist natürlich etwas übertrieben, aber es ist eine schnelle und schmutzige Methode, um zu überprüfen, ob es tatsächlich ein Problem mit Berechtigungen gibt
Nginx hat keine Berechtigung zum Schreiben in den Socket. Es hat mir geholfen, den entsprechenden Modus mit dem folgenden Befehl zu gewähren.
chmod 0755 /to/project
Ich habe Ihren Kommentar zu https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-uwsgi-and-nginx-on-ubuntu-16-04 gesehen.
versuchen Sie, Sudo /etc/init.d/nginx start
auszuführen. Versuchen Sie dann, http: // server_domain_oder_IP zu öffnen.
Wenn es funktioniert, geben Sie which uwsgi
ein, um den richtigen uwsgi-Pfad zu finden, und ändern Sie "/etc/systemd/system/myproject.service".
veränderung
Environment="PATH=/home/sammy/myproject/myprojectenv/bin" ExecStart=/home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini
in den realen Pfad anstelle von env path.
Ich finde dieses Problem durch diesen Befehl heraus.
Gleiches Problem.
Aber ich gebe die 666 Erlaubnis und starte alles neu, und es funktioniert.
Ich denke, das Fehlerprotokoll zeigt nur die eine mögliche Ursache des Problems. Während journalctl -u <yourproject>.service
Befehl Hilfe präsentieren einen anderen Grund.
Mein Fehlerprotokoll sagt mir auch, dass er den "myproject.socket" nicht finden kann. Aber .ini hat uns schon beim Aufbau geholfen. Dann erhalte ich folgende Fehlermeldung: myproject.service: Fehler beim Start von USER ~/bin/uwsgi: Kein solcher Prozess
Vielleicht ist es das Problem der Erlaubnis.
Wie bereits erwähnt, handelt es sich bei dem 502-Fehler um Socket-Berechtigungen (möglicherweise wird Permission denied
Fehler bei /var/log/nginx/error.log
). Es scheint jedoch alles zu funktionieren, da
your_user:www-data
www-data:www-data
(es ist in Nginx .conf-Datei konfiguriert)Das eigentliche Problem ist, dass nginx kann keine Verbindung zu dem Socket in Ihrem Home-Verzeichnis herstellen!
Die Lösung ist also einfach: Verschieben Sie die Socket-Datei einfach an einen anderen Ort. Zum Beispiel zu /tmp/
oder /var/www/...
Ordner.
Lösung:
Erstellen Sie Verzeichnisse
Sudo mkdir /var/www/your_project
Sudo chown your_user:www-data /var/www/your_project
Ändern Sie your_project.ini
socket = /var/www/your_project/your_project.sock
Ändern Sie den Nginx-Serverblock
uwsgi_pass unix:///var/www/your_project/your_project.sock;
Starten Sie uWSGI und nginx neu
Sudo systemctl restart your_project_service
Sudo systemctl restart nginx
Und jetzt muss alles funktionieren.
Versuchen Sie es mit myapp/bin/uwsgi --ini myapp.ini
um den tatsächlichen Fehler zu sehen, der die Ausführung von uwsgi verhindert.
In meinem Fall waren 5 Prozesse in der INI-Konfigurationsdatei zu viel für meine CPU zu handhaben. Dies war meine Fehlerausgabe.
your processes number limit is 3900 your memory page size is 4096 bytes detected max file descriptor number: 1024
In diesem Fall funktioniert es möglicherweise, wenn Sie die Anzahl der Prozesse in Ihrer INI-Datei auf 2 verringern.