sock run php5 permission invalid failed error unix nginx php

unix - php5 - nix:/ var run php fpm php fpm sock failed 13 permission denied



error de conexión nginx a php5-fpm.sock fallido(13: permiso denegado) (20)

Acabo de recibir este error otra vez hoy, ya que actualicé mi máquina (con actualizaciones para PHP) con Ubuntu 14.04 . El archivo de configuración de distribución /etc/php5/fpm/pool.d/www.conf está bien y no requiere ningún cambio actualmente.

He encontrado los siguientes errores:

dmesg | grep php [...] [ 4996.801789] traps: php5-fpm[23231] general protection ip:6c60d1 sp:7fff3f8c68f0 error:0 in php5-fpm[400000+800000] [ 6788.335355] traps: php5-fpm[9069] general protection ip:6c5d81 sp:7fff98dd9a00 error:0 in php5-fpm[400000+7ff000]

Lo extraño es que tengo 2 sitios ejecutando que utilizan PHP-FPM en esta máquina, uno funcionaba bien y el otro (una instalación Tiny Tiny RSS) me dio un 502, donde ambos han estado funcionando bien antes .

Comparé ambos archivos de configuración y encontré que fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; Faltaba para el sitio afectado.

Ambos archivos de configuración ahora contienen el siguiente bloque y se ejecutan correctamente de nuevo:

location ~ /.php$ { fastcgi_pass unix:/var/run/php5-fpm.sock; include /etc/nginx/snippets/fastcgi-php.conf; }

Actualizar

Cabe señalar que Ubuntu incluye dos archivos de parámetros relacionados con fastcgi y también un fragmento de configuración que está disponible desde Vivid y también en la versión PPA . La solución se actualizó en consecuencia.

Diff de los archivos de parámetros de fastcgi:

$ diff -up fastcgi_params fastcgi.conf --- fastcgi_params 2015-07-22 01:42:39.000000000 +0200 +++ fastcgi.conf 2015-07-22 01:42:39.000000000 +0200 @@ -1,4 +1,5 @@ +fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type;

Fragmento de configuración en /etc/nginx/snippets/fastcgi-php.conf

# regex to split $uri to $fastcgi_script_name and $fastcgi_path fastcgi_split_path_info ^(.+/.php)(/.+)$; # Check that the PHP script exists before passing it try_files $fastcgi_script_name =404; # Bypass the fact that try_files resets $fastcgi_path_info # see: http://trac.nginx.org/nginx/ticket/321 set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; fastcgi_index index.php; include fastcgi.conf;

Actualicé nginx a 1.4.7 y php a 5.5.12 , luego de eso recibí el error 502 . Antes de actualizar todo funciona bien.

nginx-error.log

2014/05/03 13:27:41 [crit] 4202#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xx.xx, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xx.xx.xx.xx"

nginx.conf

user www www; worker_processes 1; location / { root /usr/home/user/public_html; index index.php index.html index.htm; } location ~ [^/]/.php(/|$) { fastcgi_split_path_info ^(.+?/.php)(/.*)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/home/user/public_html$fastcgi_script_name; include fastcgi_params; }

Básicamente, todas las correcciones aquí mencionadas aquí básicamente habilitan el agujero de seguridad nuevamente.

Lo que terminé haciendo es agregar las siguientes líneas a mi archivo de configuración de PHP-FPM.

listen.owner = www-data listen.group = www-data

Asegúrese de que www-data sea realmente el usuario con el que se está ejecutando el trabajador nginx. Para debian es www-data por defecto.

Hacerlo de esta manera no habilita el bugs.php.net/bug.php?id=67060 .

Cambié el sistema operativo en mi servidor varias veces intentando obtener el sistema más cómodo.

Solía ​​funcionar muy bien la mayor parte del tiempo, pero finalmente obtuve este error 502 Gateway.

Utilizo un socket php fpm para cada cuenta en lugar de mantener el mismo para todos. Entonces, si uno falla, al menos las otras aplicaciones siguen funcionando.

Solía ​​tener usuarios y grupos de datos www. Pero esto cambió en mi Debian 8 con las últimas Nginx 1.8 y php5-fpm.

El usuario predeterminado es nginx y también lo es el grupo. Para estar seguro de esto, la mejor manera es verificar los archivos / etc / group y / etc / passwd. Estos no pueden mentir.

Ahí encontré que ahora tengo nginx en ambos y ya no www-data.

Quizás esto pueda ayudar a algunas personas que aún intentan descubrir por qué sigue apareciendo el mensaje de error.

Funcionó para mí.

Como alternativa a la ampliación de permisos en su configuración de php, puede cambiar el usuario especificado en su configuración de nginx.

En la primera línea de su extracto nginx.conf anterior, el usuario y el grupo se especifican como www y www, respectivamente.

user www www;

Mientras tanto, su configuración php probablemente especifica un usuario y un grupo de www-data:

listen.owner = www-data listen.group = www-data

Puede cambiar la línea en su nginx.conf, a cualquiera de los siguientes, entonces:

user www-data www; user www-data www-data; # or any group, really, since you have the user matching user www www-data; # requires that your php listen.mode gives rw access to the group

Compruebe qué usuario ejecuta nginx. A partir de Ubuntu 12.04, nginx lo ejecuta el usuario nginx que no es miembro del grupo www-data.

usermod -a -G www-data nginx

y reiniciar los demonios nginx y php5-fpm resuelve el problema.

De hecho, "listen.mode" debe ser: "0660" y no "0666", ya que Other Writable u Other Readable nunca es una buena opción aquí.

Así que trate de averiguar qué usuario / grupo ejecuta su servidor web. Uso CentOs y se ejecuta como usuario "nginx". Entonces agréguelo a su php-fpm.conf:

listen.owner = nginx listen.group = nginx listen.mode = 0660

finalmente reiniciar php-fpm

Después de actualizar de Ubuntu 14.04 lts a Ubuntu 16.04 lts encontré una razón más para este error que no había visto antes.

Durante el proceso de actualización, de alguna manera perdí mi ejecutable php5-fpm por completo. Todos los archivos de configuración estaban intactos y me tomó un tiempo darme cuenta de que el service php5-fpm start no comenzó realmente un proceso, ya que no mostraba ningún error.

Mi momento de despertar fue cuando noté que no había ningún archivo de socket en /var/run/php5-fpm.sock , como debería haber, ni tampoco netstat -an muestra procesos escuchando en el puerto que intenté como alternativa mientras intentaba para resolver este problema. Como el archivo / usr / sbin / php5-fpm tampoco existía, finalmente estaba en el camino correcto.

Para resolver este problema actualicé php de la versión 5.5 a 7.0. apt-get install php-fpm hizo el truco como efecto secundario. Después de eso e instalando otros paquetes necesarios, todo volvió a la normalidad.

Sin embargo, esta solución de actualización puede tener problemas propios . Dado que PHP ha evolucionado bastante, es posible que el software se rompa de manera inimaginable. Por lo tanto, a pesar de que fui por ese camino, es posible que desee conservar la versión que le gusta solo por un tiempo más.

Afortunadamente, parece que hay una forma clara de hacerlo , como se describe en el sitio de Customize Windows:

add-apt-repository ppa:ondrej/php apt-get purge php5-common apt-get update apt-get install php5.6

Una solución más limpia como podría ser, no lo intenté. Espero que el próximo par de días me diga si debería haberlo hecho.

El problema en mi caso fue que el servidor web Nginx se estaba ejecutando como usuario nginx y el grupo se estaba ejecutando como usuario www-data.

Resolví el problema cambiando el usuario en el que se está ejecutando Nginx en el archivo /etc/nginx/nginx.conf (podría ser diferente en su sistema, el mío es Ubuntu 16.04.1)

Cambio: user nginx;

a: user www-data;

luego reinicie Nginx: service nginx restart

He solucionado el mismo problema en Amazon Linux AMI 2016.09 (Centos 7) siguiendo estos pasos.

Abra sus archivos www.conf (Ejemplo: sudo nano /etc/php-fpm.d/www.conf) Por último, encuentre las líneas que configuran listen.owner y listen.group y cambie sus valores de "nobody" a "nginx ":

listen.owner = nginx listen.group = nginx listen.mode = 0666

Por último, encuentre las líneas que configuran el usuario y el grupo y cambie sus valores de "apache" a "nginx":

user = nginx group = nginx

Reinicie php-fpm (sudo service php-fpm restart)

La siguiente solución simple funcionó para mí, evitando posibles problemas de permisos con el socket.

En su configuración de nginx, establezca fastcgi_pass en:

fastcgi_pass 127.0.0.1:9000;

En lugar de

fastcgi_pass /var/run/php5-fpm.sock;

Esto debe coincidir con el parámetro listen = en /etc/php5/fpm/pool.d/www.conf, así que también establezca esto en:

listen = 127.0.0.1:9000;

Luego reinicie php5-fpm y nginx

service php5-fpm restart

Y

service nginx restart

Para obtener más información, consulte: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

La solución de @ Xander funciona, pero no persiste después de un reinicio.

Descubrí que tenía que cambiar listen.mode a 0660 en /etc/php5/fpm/pool.d/www.conf .

Muestra de www.conf:

; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0660 ;listen.owner = www-data ;listen.group = www-data ;listen.mode = 0660

Edición: Según @Chris Burgess, he cambiado esto al método más seguro.

Quité el comentario para listen.mode, .group y .owner:

listen.owner = www-data listen.group = www-data listen.mode = 0660

/ var / run Only contiene información sobre el sistema en ejecución desde el último arranque, por ejemplo, los usuarios que han iniciado sesión y los demonios en ejecución. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Nota al margen:

Mi php5-fpm -v Informes: PHP 5.4.28-1+deb.sury.org~precise+1 . El problema ocurrió después de una actualización reciente también.

Para aquellos que intentaron todo en este hilo y aún se atascaron: Esto resolvió mi problema. Actualicé /usr/local/nginx/conf/nginx.conf

  1. Descomenta la línea diciendo user

  2. Haz que sea www-data para que se convierta en: user www-data;

  3. Guárdalo (se requiere acceso a la raíz)

  4. Reinicie nginx

Sencillo pero funciona ..

listen.owner = nginx listen.group = nginx chown nginx:nginx /var/run/php-fpm/php-fpm.sock

Si ha intentado todo en esta publicación pero no está teniendo éxito para que PHP funcione, esto es lo que lo solucionó en mi caso:

Asegúrese de tener estas líneas sin comentarios en /etc/php5/fpm/pool.d/www.conf:

listen.owner = www-data listen.group = www-data listen.mode = 0660

Asegúrese de que / etc / nginx / fastcgi_params tenga este aspecto:

fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param HTTPS $https if_not_empty; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; # PHP only, required if PHP was built with --enable-force-cgi-redirect fastcgi_param REDIRECT_STATUS 200;

Estas dos líneas faltaban de mi / etc / nginx / fastcgi_params, ¡asegúrate de que estén ahí!

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_script_name;

Luego, reinicie php5-fpm y nginx. Debería hacer el truco.

Si tiene un grupo diferente por usuario, asegúrese de que el usuario y el grupo estén configurados correctamente en el archivo de configuración. Puede encontrar el usuario nginx en el archivo /etc/nginx/nginx.conf. El grupo nginx es el mismo que el usuario nginx.

user = [pool-user] group = [pool-group] listen.owner = [nginx-user] listen.group = [nginx-group]

Si tienes declaraciones

pid = /run/php-fpm.pid

y

listen = /run/php-fpm.pid

en diferentes archivos de configuración, entonces la raíz será propietaria de este archivo.

Solo para agregar, en CentOS (y probablemente Red Hat y Fedora) el archivo para cambiar los permisos está en:

/etc/php-fpm.d/www.conf

También debe tenerse en cuenta a sus grupos de FPM individuales, si los hay.

No pude entender por qué ninguna de estas respuestas funcionó para mí hoy. Este había sido un escenario de configuración y olvido para mí, en el que había olvidado que listen.user y listen.group se duplicaron para cada grupo.

Si usó grupos para diferentes cuentas de usuario como lo hice yo, donde cada cuenta de usuario posee sus procesos y sockets FPM, la configuración de las opciones de configuración de listen.owner y listen.group predeterminadas en ''nginx'' simplemente no funcionará. Y, obviamente, tampoco es aceptable dejar que ''nginx'' los posea a todos.

Para cada piscina , asegúrese de que

listen.group = nginx

De lo contrario, puede dejar la propiedad de la piscina y tal, solo.

Tuve un error similar después de la actualización de PHP. PHP corrigió un bugs.php.net/bug.php?id=67060 donde o tenía permiso de rw para el archivo de socket.

  1. Abra /etc/php5/fpm/pool.d/www.conf o /etc/php/7.0/fpm/pool.d/www.conf , dependiendo de su versión.

  2. Descomentar todas las líneas de permiso, como:

    listen.owner = www-data listen.group = www-data listen.mode = 0660

  3. Reinicie fpm - sudo service php5-fpm restart o sudo service php7.0-fpm restart

Nota : si su servidor web se ejecuta como un usuario distinto de www-data, deberá actualizar el archivo www.conf corresponde.

Verifique también SELINUX (/ etc / selinux):

# getenforce

apágalo:

# setenforce 0