web-dev-qa-db-de.com

Nginx Django und Gunicorn. Gunicorn Sockenfeile fehlt?

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

9
kalo

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:

  • In meinem Fall, als dies passierte, kam Gunicorn nie dazu, Fehler zu protokollieren, also musste ich woanders suchen. Versuchen Sie ps auxf | grep gunicorn, um festzustellen, ob Mitarbeiter im Einsatz sind. Habe ich nicht.
  • Das Durchsuchen des Syslogs nach Beschwerden von Emporkömmlingen, 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:

    • Django-Fehler (vielleicht Probleme beim Laden Ihres Einstellungsmoduls?). Stellen Sie sicher, dass Ihre wsgi.py auf das entsprechende Einstellungsmodul auf dem Server verweist.
    • whitespace-Probleme in Ihrem Upstart-Skript. Ich hatte eine Lasche, die sich zwischen Räumen versteckte, in denen Dinge vermisteten.
    • benutzer-/Berechtigungsprobleme. Schließlich konnte ich gunicorn als root auf der Kommandozeile ausführen, aber nicht als Nicht-Root-Benutzer über die Upstart-Konfiguration.

Hoffentlich hilft das. Es ist ein paar lange Tage her, dieses Zeug aufzuspüren.

22
swendr

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

  1. Sudo Laufordner löschen.
  2. Erstellen Sie es ohne Sudo-Berechtigungen neu.
  3. Führen Sie Gunicorn erneut aus.
  4. ????
  5. Profitieren

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.

1
Henry Lynx

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. keine Live-Upstreams beim Herstellen einer Verbindung zum Upstream
  2. * 4 connect () to unix: /myproject.sock ist fehlgeschlagen (13: Berechtigung verweigert), während eine Verbindung zum Upstream hergestellt wird
  3. gunicorn OSError: [Errno 1] Operation nicht erlaubt
  4. * 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:

  1. Melden Sie sich als Root-Benutzer am System an
  2. Erstellen Sie das Verzeichnis/home/nginx.
  3. Folgen Sie danach den Anweisungen auf der Website bis Erstellen Sie ein Upstart-Skript.
  4. Führen Sie chown -R nginx aus: nginx/home/nginx
  5. Führen Sie für das Upstart-Skript die folgende Änderung in der letzten Zeile durch: exec gunicorn --workers 3 --bind Unix: myproject.sock -u nginx -g nginx wsgi NICHT HINZUFÜGEN -m, da dies den Socket durcheinander bringt. Aus der Dokumentation von Gunicorn wird Python, wenn -m Standard ist, die beste Berechtigung ermitteln
  6. Starten Sie das Upstart-Skript
  7. 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

    1. Starten Sie nun den nginx-Server neu und Sie können loslegen.
0
Shravan Shetty