web-dev-qa-db-fra.com

Nginx Django et Gunicorn. Le fichier de chaussettes Gunicorn est manquant?

J'ai un ansible approvisionné VM sur la base de celui-ci https://github.com/jcalazan/ansible-Django-stack mais pour une raison quelconque, le fait de démarrer Gunicorn donne l'erreur suivante:

Impossible de se connecter à /path/to/my/gunicorn.sock

et dans le fichier journal nginx:

connect () à unix: /path/to/my/gunicorn.sock a échoué (2: aucun fichier ou répertoire de ce type) lors de la connexion à l'amont

Et en fait, le fichier de socket est manquant dans le répertoire spécifié. J'ai vérifié les permissions du répertoire et elles vont bien.

Voici mon script gunicorn_start:

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

Quelqu'un peut-il suggérer quoi d'autre pourrait causer le fichier de socket manquant?

Merci

pythondjangopython-2.7nginxgunicorn
9
kalo

Eh bien, comme je n'ai pas assez de représentants pour commenter, je mentionnerai ici qu'il n'y a pas beaucoup de spécificité suggérée par le socket manquant, mais je peux vous en dire un peu plus sur la façon dont j'ai commencé à vous mettre à la place des choses. travail.

En résumé, gunicorn a rencontré un problème lorsqu'il a été exécuté par le débutant et qu'il n'a jamais été mis en service ou arrêté. Voici quelques étapes qui peuvent vous aider à obtenir plus d'informations pour identifier votre problème:

  • Dans mon cas, lorsque cela s'est produit, gunicorn n'a jamais consigné d'erreurs dans la journalisation des erreurs. J'ai donc dû chercher ailleurs. Essayez ps auxf | grep gunicorn pour voir si vous avez des travailleurs. Je n'ai pas.
  • Le fait de regarder dans le syslog pour connaître les plaintes de upstart, grep init: /var/log/syslog, m’a montré que mon service de tireurs de fusils avait été arrêté parce qu’il revenait trop vite, bien que je doute que ce soit votre problème, car vous n’avez pas de délai de réapparition. Peu importe, vous pourriez y trouver quelque chose.

  • Après avoir constaté que gunicorn ne parvenait pas à exécuter ou à enregistrer les erreurs, j'ai décidé de l'exécuter à partir de la ligne de commande. Accédez au répertoire où réside le fichier manage.py et exécutez la version développée de votre commande upstart sur votre instance gunicorn. Quelque chose comme (remplacez tous les vars par les littéraux appropriés au lieu des ordures que j'utilise):

    /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

  • Si vous êtes chanceux, vous pouvez obtenir une trace python ou trouver quelque chose dans votre journal des erreurs gunicorn après avoir exécuté la commande manuellement. Certaines choses qui peuvent mal se passer:

    • Erreurs Django (peut-être des problèmes de chargement de votre module de paramètres?). Assurez-vous que votre fichier wsgi.py référence le module de paramètres approprié sur le serveur.
    • problèmes d'espaces dans votre script de démarrage. J'avais un onglet caché parmi des espaces qui fourraient des objets.
    • problèmes utilisateur/autorisation. Enfin, j’ai pu exécuter gunicorn en tant que root sur la ligne de commande, mais pas en tant qu’utilisateur non root via la configuration ascendante.

J'espère que cela pourra aider. Cela fait deux ou trois longues journées à la recherche de ces choses.

22
swendr

J'ai rencontré le même problème après avoir suivi le grand guide de Michal Karzynski ' Configuration de Django avec Nginx, Gunicorn, Virtualenv, superviseur et PostgreSQL '.

Et voici comment je l'ai résolu.

J'avais cette variable dans le script bash utilisée pour démarrer gunicorn via Supervisor (myapp/bin/gunicorn_start):

SOCKFILE={{ myapp absolute path }}/run/gunicorn.sock

Qui, lorsque vous exécutez le script bash pour la première fois, crée un dossier 'run' et un fichier de chaussettes utilisant les privilèges root. J'ai donc supprimé le dossier d'exécution, puis je l'ai recréé sans privilèges Sudo et le tour est joué! Maintenant, si vous relancez Gunicorn ou Supervisor, vous n'aurez plus le message d'erreur du fichier chaussette manquant!

TL; DR

  1. Sudo supprimer le dossier d'exécution.
  2. Recréez-le sans les privilèges Sudo.
  3. Exécutez à nouveau Gunicorn.
  4. ????
  5. Profit
8
BringBackCommodore64

J'ai eu le même problème et j'ai découvert que j'avais défini Django_SETTINGS_MODULE sur les paramètres de production du script gunicorn et que les paramètres wsgi utilisaient dev.

J'ai pointé Django_SETTINGS_MODULE sur dev et tout a fonctionné.

1
Henry Lynx

Eh bien, j'ai travaillé sur cette question pendant plus d'une semaine et j'ai finalement été capable de comprendre. Veuillez suivre les liens de Digital Ocean , mais ils n’ont pas identifié les problèmes importants qui incluent

  1. pas de vie en amont lors de la connexion en amont
  2. * 4 connect () à unix: /myproject.sock a échoué (13: autorisation refusée) lors de la connexion à l'amont
  3. gunicorn OSError: [Errno 1] Opération non autorisée.

  4. * 1 connect () à unix: /tmp/myproject.sock a échoué (2: aucun fichier ou répertoire de ce type)

    etc.

Il s’agit essentiellement de problème d’autorisation pour la connexion entre Nginx et Gunicorn . Pour simplifier les choses, je recommandepour donner la même autorisation nginxà chaque fichier/projet/programme Python que vous créez.

Pour résoudre tout le problème, suivez cette approche: La première chose à faire est:

  1. Connectez-vous au système en tant qu'utilisateur root.
  2. Créez le répertoire/home/nginx.
  3. Après cela, suivez les instructions du site Web jusqu’à Créer un script de démarrage immédiat.
  4. Exécutez chown -R nginx: nginx/home/nginx
  5. Pour le script de démarrage, apportez les modifications suivantes à la dernière ligne: exec gunicorn --workers 3 --indiquez unix: myproject.sock -u nginx -g nginx wsgi N'Ajoutez pas la permission, car elle gâche le socket. Dans la documentation de Gunicorn, lorsque -m est la valeur par défaut, python déterminera la meilleure autorisation
  6. Lancer le script de démarrage

  7. Allez maintenant dans le fichier /etc/nginx/nginx.conf. Allez au module serveur et ajoutez:

    location/{include proxy_params; proxy_pass http <>: <> // unix: /home/nginx/myproject.sock; } REMOVE <> Ne suivez pas l'aricle digitalocean à partir d'ici

    1. Maintenant, redémarrez le serveur Nginx et vous êtes prêt à partir.
0
Shravan Shetty