Мы развернули наше приложение rails на nginx и пассажирах. Периодически страницы приложения загружаются частично. В журнале нет ошибок, но журнал ошибок nginx показывает следующее:
2011/02/14 05:49:34 [crit] 25389#0: *645 open() "/opt/nginx/proxy_temp/2/02/0000000022" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: y.y.y.y, request: "GET /signup/procedures?count=0 HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "y.y.y.y", referrer: "http://y.y.y.y/signup/procedures"
У меня была такая же проблема с настройкой NGINX / PHP-FPM (php-fpm = улучшенный fcgi для php).
Вы можете узнать, от имени какого пользователя запущены процессы nginx
ps aux | grep "nginx: worker process"
А затем проверьте правильность разрешений в ваших прокси-файлах.
ls -l /opt/nginx/proxy_temp/
В моем случае nginx работал как www-data и два каталога в моем прокси-каталоге принадлежали root.
Я пока не знаю, как это произошло, но я исправил это, выполнив (как root)
chown www-data.www-data /opt/nginx/proxy_temp
Вы, вероятно, начали с пользователя root, а затем изменили его. Теперь проблема в том, что папки кеша, т.е.
/var/cache/nginx/client_temp
/var/cache/nginx/fastcgi_temp
/var/cache/nginx/proxy_temp
/var/cache/nginx/scgi_temp
/var/cache/nginx/uwsgi_temp
уже принадлежат root, поэтому ваш пользователь nginx (или что-то еще, на что вы пытаетесь переключиться) не может получить к ним доступ, потому что у них есть разрешение 700.
Так что решение простое. Остановите nginx, затем:
rm -rf /var/cache/nginx/*
или по другому пути в вашем дистрибутиве и выпустите. Затем перезапустите nginx, который повторно создаст эти папки с соответствующими разрешениями.
Также проверьте файл nginx.conf, чтобы убедиться, что вы указываете правильный пользователь И группу.
У меня возникла проблема, когда разрешения для каталога были настроены для имени пользователя / nginx, но пользователь nginx.conf указал только имя пользователя. По умолчанию, если директиве user не задана группа, она использует то же имя, что и user. Итак, имя пользователя / имя пользователя пытались получить доступ к каталогу вместо имени пользователя / nginx. Обновление конфигурации устранило мои проблемы.
Итак, я сделал все вышеперечисленное, и, к сожалению, для меня это привело к той же ошибке. Я запускаю приложение rails, упакованное в файл jar с крутящим моментом на машине centos 6.7 с nginx. Я боролся с этим около 3 часов, пока не нашел другое решение, и я надеюсь, что это поможет кому-то другому. В соответствии с Эта статья nginx может работать в принудительном режиме. Я просто переключил nginx в разрешающий режим с помощью
setenforce 0
После этого ошибка исчезла, и я смог запустить свое приложение в промежуточной / производственной среде.
Я был в неведении, пока не нашел ошибку в audit.log
type=AVC msg=audit(1444454198.438:466): avc: denied { name_connect } for pid=3201 comm="nginx" dest=8080 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket
Я очень надеюсь, что это сэкономит кому-то те 3 часа, которые я только что потерял.
При запуске nginx из непривилегированной учетной записи use_temp_path=off.
proxy_cache_path ... use_temp_path=off;
Это необходимо, чтобы избежать попытки nginx поместить файлы в значения по умолчанию. proxy_temp_path. Из документации nginx:
Каталог для временных файлов устанавливается на основе параметра use_temp_path (1.7.10). Если этот параметр опущен или установлен в значение on, будет использоваться каталог, установленный директивой proxy_temp_path для данного местоположения. Если значение отключено, временные файлы будут помещены непосредственно в каталог кеша.
chmod 777 /opt/nginx/proxy_temp/
У меня была такая же проблема, и она была решена с помощью chmod в этот каталог.