Nginx ne peut pas trouver de fichier de socket unix à la Licorne (aucun fichier ou répertoire)
Je suis le déploiement d'un Rails 4 application à une Fedora 19 x64, server à l'aide de Nginx et la Licorne. Le problème est que j'obtiens une erreur lors de la visite de l'adresse: "Nous sommes désolés, mais quelque chose s'est mal passé."
Mon Nginx journal des erreurs (/var/log/nginx/error.log
) montre:
2014/03/08 03:50:12 [warn] 23934#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2014/03/08 03:50:12 [warn] 23936#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2014/03/08 03:50:14 [crit] 23939#0: *1 connect() to unix:/tmp/unicorn.[app name].sock failed (2: No such file or directory) while connecting to upstream, client: [client IP], server: localhost, request: "GET /v1/industries/1.xml HTTP/1.1", upstream: "http://unix:/tmp/unicorn.[app name].sock:/v1/industries.json", host: "api.[app name].ca"
Aussi loin que je peux voir à partir de cela, Nginx n'est pas au courant que le support existe. Cependant, en regardant dans /tmp
, c'est fait:
[root@localhost tmp]# ls
unicorn.[app name].sock
Je reçois coincé à ce stade, peu importe comment je modifier ma Licorne fichier de configuration ou mon fichier de configuration de Nginx. Les deux sont attacted:
/var/www/[nom de l'application]/config/licorne.rb:
working_directory "/var/www/[app name]"
pid "/var/www/[app name]/pids/unicorn.pid"
stderr_path "/var/www/[app name]/log/unicorn.log"
stdout_path "/var/www/[app name]/log/unicorn.log"
listen "/tmp/unicorn.[app name].sock"
worker_processes 2
timeout 30
/etc/nginx/conf.d/par défaut.conf:
upstream app {
server unix:/tmp/unicorn.[app name].sock fail_timeout=0;
}
server {
listen 80;
server_name localhost;
root /var/www/[app name]/public;
try_files $uri/index.html $uri @app;
location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}
La façon dont j'ai été le démarrage de ces deux démons est comme suit:
unicorn_rails -c /var/www/[app name]/config/unicorn.rb -D -E production
service nginx start
La Licorne journaux contiennent pas d'informations pertinentes, ni de la production de journaux. Cette configuration semble tout droit vers l'avant, quelqu'un a vécu cela avant? Merci pour toute aide que vous pouvez fournir.
En passant, j'ai d'abord été suivant ce tutoriel: https://www.digitalocean.com/community/articles/how-to-deploy-rails-apps-using-unicorn-and-nginx-on-centos-6-5
Vous devez vous connecter pour publier un commentaire.
Après de nombreuses heures et un grand total de 3 bières, j'ai réussi à comprendre le problème. Après des heures de creuser, je suis finalement tombé sur ce Serveur Faute de réponse
En d'autres termes, il apparaît que les programmes qui créent des fichiers dans
/tmp
(ou/var/tmp
comme je l'ai découvert) sont les seuls programmes qui sont en mesure de voir les fichiers dans ce répertoire. Licorne a été la création de la socket UNIX fichier, cependant Nginx ne pouvais pas le voir.La solution que j'ai utilisé est d'avoir de la Licorne créer des sockets en
/var/sockets
.listen "/var/sockets/unicorn.[app name].sock"
, puis configurer Nginx pour proxy toutes les connexions à votre serveur pour que le fichier de socket commeserver unix:/var/sockets/unicorn.[app name].sock fail_timeout=0;
504 Gateway Timeout
d'erreur lors de l'utilisation en amont de puma serveur. La seule raison pour laquelle je suis tombé sur cette réponse a été que les journaux indiqué la même chose étrange à la recherchehttp://unix:///tmp…
chemin à explorer. Alors, oui, certainement pas une licorne bug spécifique au cas où quelqu'un d'autre à l'aide de puma, ou n'importe quel autre serveur, conclut que cette. Ubuntu 14.04 est apparemment présentant le même protocole de sécurité que fedora.J'ai soudain eu une situation similaire après un changement de nginx à utiliser systemd service de démarrage basé sur leur modèle.
Il se termine que le problème était avec
PrivateTmp=true
, ce qui fait en sorte que nginx est impossible d'accéder au fichier de socket créé par gunicorn. Une fois que j'ai changé de cePrivateTmp=false
l'erreur résolue.