Ich habe ein ansible bereitgestelltes VM basierend auf diesem https://github.com/jcalazan/ansible-Django-stack aber aus irgendeinem Grund gibt der Versuch Gunicorn zu starten den folgenden Fehler aus
Es kann keine Verbindung zu /path/to/my/gunicorn.sock hergestellt werden
und in der Nginx-Protokolldatei:
connect () to unix: /path/to/my/gunicorn.sock fehlgeschlagen (2: Keine solche Datei oder kein solches Verzeichnis) beim Herstellen der Verbindung zum Upstream
Und tatsächlich fehlt die Socket-Datei im angegebenen Verzeichnis. Ich habe die Berechtigungen des Verzeichnisses überprüft und sie sind in Ordnung.
Hier ist mein gunicorn_start Skript:
NAME="{{ application_name }}"
DJANGODIR={{ application_path }}
SOCKFILE={{ virtualenv_path }}/run/gunicorn.sock
USER={{ gunicorn_user }}
GROUP={{ gunicorn_group }}
NUM_WORKERS={{ gunicorn_num_workers }}
# Set this to 0 for unlimited requests. During development, you might want to
# set this to 1 to automatically restart the process on each request (i.e. your
# code will be reloaded on every request).
MAX_REQUESTS={{ gunicorn_max_requests }}
echo "Starting $NAME as `whoami`"
# Activate the virtual environment.
cd $DJANGODIR
. ../../bin/activate
# Set additional environment variables.
. ../../bin/postactivate
# Create the run directory if it doesn't exist.
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR
# Programs meant to be run under supervisor should not daemonize themselves
# (do not use --daemon).
exec gunicorn \
--name $NAME \
--workers $NUM_WORKERS \
--max-requests $MAX_REQUESTS \
--user $USER --group $GROUP \
--log-level debug \
--bind unix:$SOCKFILE \
{{ application_name }}.wsgi
Kann jemand vorschlagen, was sonst noch die fehlende Socket-Datei verursachen könnte?
Vielen Dank
Nun, da ich nicht genug Repräsentanten habe, um einen Kommentar abzugeben, möchte ich hier erwähnen, dass die fehlende Buchse nicht sehr spezifisch ist, aber ich kann Ihnen ein wenig darüber erzählen, wie ich in Ihren Schuhen angefangen habe und was zu tun ist Arbeit.
Das lange und kurze daran ist, dass Gunicorn auf ein Problem gestoßen ist, wenn es von Emporkömmlingen betrieben wird und entweder nie zum Laufen gekommen ist oder heruntergefahren wurde. Mit den folgenden Schritten erhalten Sie möglicherweise weitere Informationen, um Ihr Problem aufzuspüren:
ps auxf | grep gunicorn
, um festzustellen, ob Mitarbeiter im Einsatz sind. Habe ich nicht.grep init: /var/log/syslog
, hat mir gezeigt, dass mein Gunicorn-Dienst gestoppt wurde, weil er zu schnell nachgearbeitet hat, obwohl ich bezweifle, dass dies Ihr Problem sein wird, da Sie in Ihrem Conf keinen Respawn haben. Egal, Sie könnten dort etwas finden.Nachdem ich festgestellt hatte, dass Gunicorn nicht ausgeführt werden konnte oder Fehler protokollierte, habe ich beschlossen, es über die Befehlszeile auszuführen. Wechseln Sie in das Verzeichnis, in dem sich Ihr manage.py befindet, und führen Sie die erweiterte Version Ihres Befehls upstart für Ihre Gunicorn-Instanz aus. So etwas wie (Ersetzen Sie alle Vars durch die entsprechenden Wurfmaterialien anstelle des Mülls, den ich benutze.):
/path/to/your/virtualenv/bin/gunicorn --name myapp --workers 4 --max-requests 10 --user appuser --group webusers --log-level debug --error-logfile /somewhere/I/can/find/error.log --bind unix:/tmp/myapp.socket myapp.wsgi
Wenn Sie Glück haben, erhalten Sie möglicherweise ein Python-Traceback oder finden etwas in Ihrem Gunicorn-Fehlerprotokoll, nachdem Sie den Befehl manuell ausgeführt haben. Einige Dinge, die schief gehen können:
Hoffentlich hilft das. Es ist ein paar lange Tage her, dieses Zeug aufzuspüren.
Ich bin auf dasselbe Problem gestoßen, nachdem ich Michal Karzynskis großartigem Leitfaden ' Einrichten von Django mit Nginx, Gunicorn, virtualenv, Supervisor und PostgreSQL ' gefolgt bin.
Und so habe ich es gelöst.
Ich hatte diese Variable im Bash-Skript, mit der gunicorn über Supervisor gestartet wurde (myapp/bin/gunicorn_start):
SOCKFILE={{ myapp absolute path }}/run/gunicorn.sock
Wenn Sie das Bash-Skript zum ersten Mal ausführen, werden ein 'run'-Ordner und eine Sock-Datei mit Root-Rechten erstellt. Also habe ich Sudo den Run-Ordner gelöscht und ihn dann ohne Sudo-Privilegien und voila neu erstellt! Wenn Sie Gunicorn oder Supervisor erneut ausführen, wird die nervige Fehlermeldung "Fehlende Socken-Datei" nicht mehr angezeigt.
TL; DR
Ich hatte das gleiche Problem und stellte fest, dass ich Django_SETTINGS_MODULE im Gunicorn-Skript auf Produktionseinstellungen gesetzt hatte und die wsgi-Einstellungen dev verwendeten.
Ich habe das Django_SETTINGS_MODULE auf dev gerichtet und alles hat funktioniert.
Nun, ich habe mehr als eine Woche an diesem Problem gearbeitet und konnte es endlich herausfinden. Bitte folgen Sie den Links von Digital Ocean , aber sie haben wichtige Themen, zu denen auch gehört, nicht genau bestimmt
* 1 connect () to unix: /tmp/myproject.sock fehlgeschlagen (2: Keine solche Datei oder Verzeichnis)
etc.
Diese Probleme sind im Grunde genommen Berechtigungsprobleme für die Verbindung zwischen Nginx und Gunicorn . Zur Vereinfachung empfehle ichum die gleiche Nginx-Berechtigung zu erteilenfür jede Datei/jedes Projekt/jedes Python-Programm, das Sie erstellen.
Um das Problem zu lösen, gehen Sie folgendermaßen vor: Das Erste ist:
Gehen Sie jetzt einfach zur Datei /etc/nginx/nginx.conf. Gehen Sie zum Servermodul und fügen Sie Folgendes hinzu:
location/{include proxy_params; proxy_pass http <>: <> // unix: /home/nginx/myproject.sock; } REMOVE <> Folgen Sie ab hier nicht mehr dem Digitalocean-Artikel