Nginx 1 FastCGI enviado en stderr: "Script primario desconocido"

La primera vez que uso Nginx, pero estoy más que familiarizado con Apache y Linux. Estoy usando un proyecto existente y cuando intento ver index.php obtengo un archivo 404 no encontrado.

Aquí está la entrada de access.log:

2013/06/19 16:23:23 [error] 2216#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.ordercloud.lh"

Y aquí está el archivo de sitios disponibles:

server {
    set $host_path "/home/willem/git/console/www";
    access_log  /www/logs/console-access.log  main;

    server_name  console.ordercloud;
    root   $host_path/htdocs;
    set $yii_bootstrap "index.php";

    charset utf-8;

    location / {
        index  index.html $yii_bootstrap;
        try_files $uri $uri/ /$yii_bootstrap?$args;
    }

    location ~ ^/(protected|framework|themes/\w+/views) {
        deny  all;
    }

    #avoid processing of calls to unexisting static files by yii
    location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
        try_files $uri =404;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php {
        fastcgi_split_path_info  ^(.+\.php)(.*)$;

        #let yii catch the calls to unexising PHP files
        set $fsn /$yii_bootstrap;
        if (-f $document_root$fastcgi_script_name){
            set $fsn $fastcgi_script_name;
        }

        fastcgi_pass   127.0.0.1:9000;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fsn;

        #PATH_INFO and PATH_TRANSLATED can be omitted, but RFC 3875 specifies them for CGI
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        fastcgi_param  PATH_TRANSLATED  $document_root$fsn;
    }

    location ~ /\.ht {
        deny  all;
    }
}

Mi / home / willem / git / console es propiedad de www-data: www-data (mi usuario web ejecuta php, etc.) y le he otorgado 777 permisos por frustración ...

Mi mejor conjetura es que algo está mal con la configuración, pero no puedo resolverlo ...

ACTUALIZACIÓN Así que lo cambié/var/www/ y usé una configuración mucho más básica:

server {
    #listen   80; ## listen for ipv4; this line is default and implied
    #listen   [::]:80 default ipv6only=on; ## listen for ipv6

    root /var/www/;
    index index.html index.htm;

    # Make site accessible from http://localhost/
    server_name console.ordercloud;

    location / {
        root           /var/www/console/frontend/www/;
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www;
            include        fastcgi_params;
    }

    location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
            try_files $uri =404;
        }

    location /doc/ {
        alias /usr/share/doc/;
        autoindex on;
        allow 127.0.0.1;
        deny all;
    }

}

Además, si llamo localhost/console/frontend/www/index.php, obtengo un 500 PHP, lo que significa que está sirviendo allí. Simplemente no está sirviendo fuera de la consola.

El mensaje de error "script primario desconocido" casi siempre está relacionado con un conjunto incorrecto SCRIPT_FILENAMEen la fastcgi_paramdirectiva nginx (o permisos incorrectos, vea otras respuestas).

Estás utilizando un ifen la configuración que publicaste primero. Bueno, ya debería saberse que si es malo y que a menudo produce problemas.

Establecer la rootdirectiva dentro de un bloque de ubicación es una mala práctica, por supuesto, funciona.

Podría intentar algo como lo siguiente:

server {
    location / {
        location ~* \.php$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_pass 127.0.0.1:9000;
            try_files $uri @yii =404;
        }
    }
    location @yii {
        fastcgi_param SCRIPT_FILENAME $document_root$yii_bootstrap;
    }
}

Tenga en cuenta que la configuración anterior no se ha probado. Debe ejecutar nginx -tantes de aplicarlo para verificar si nginx puede detectar problemas de inmediato.

No siempre es que SCRIPT_FILENAMEestá mal.
También puede ser que PHP se esté ejecutando como el usuario / grupo incorrecto .

Este ejemplo es específico para Mac OS X , que en mi experiencia es el más problemático de configurar (Debian es fácil en comparación): acabo de actualizar de PHP 5.6 a 7.0, usando homebrew y los excelentes paquetes de josegonzalez.

El problema fue que se creó una nueva copia de los archivos de configuración.

El archivo de configuración principal es /usr/local/etc/php/7.0/php-fpm.conf, pero tenga en cuenta la sección Definiciones de grupo al final, donde incluye un subdirectorio completo.

include=/usr/local/etc/php/7.0/php-fpm.d/*.conf

En php-fpm.dhay un www.confarchivo. Por defecto esto tiene:

user = _www
group = _www

En OS X, es posible que deba cambiar esto a:

user = [your username]
group = staff

(debería encontrar que esto coincide con uno ls -lhde su document_root)

Desafortunadamente, sin este cambio, aún verá esto en su registro de errores de Nginx, incluso si está buscando el archivo en el lugar correcto .

"Primary script unknown" while reading response header from upstream

Verifique lo que se está ejecutando actualmente como:

ps aux | grep 'php-fpm'

o más limpiamente:

ps aux | grep -v root | grep php-fpm | cut -d\  -f1 | sort | uniq

Cómo verificar si el nombre del archivo de script es correcto:

(robado de igorsantos07 en la otra respuesta)

Añadir al httpbloque de main /usr/local/etc/nginx/nginx.conf:

log_format scripts '$document_root$fastcgi_script_name > $request';

(donde el primer bit debe ser lo que esté usando actualmente, para que pueda ver si es correcto).

Y para usar el registro que acaba de definir, en el serverbloque de su sitio :

access_log /var/log/nginx/scripts.log scripts;

Si es correcto, solicitar example.com/phpinfo.php producirá algo como esto:

/path/to/docroot/phpinfo.php > GET /phpinfo.php

¿Puedes simplificar tu configuración existente?

¿Está utilizando un location ~ \.php {bloque que copió / pegó de algún lugar fuera de Internet? La mayoría de los paquetes le permiten hacerlo de manera más rápida y limpia. por ejemplo, en OS X ahora solo necesitas esto:

location ~ \.php {
    fastcgi_pass 127.0.0.1:9000;
    include snippets/fastcgi-php.conf;

    # any site specific settings, e.g. environment variables
}

Se encuentran cosas como fastcgi_split_path_info, try_files y fastcgi_index (por defecto index.php) /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Eso a su vez incluye /usr/local/etc/nginx/fastcgi.confcuál es una lista de fastcgi_paramconfiguraciones, incluido el crucial SCRIPT_FILENAME.

Nunca duplique rooten el bloque de ubicación PHP.

Ok, entonces 3 cosas que encontré después de un día de lucha

1. Por alguna razón, ya tenía algo ejecutándose en el puerto 9000, así que cambié a 9001
2. Mi sitio predeterminado estaba interceptando el nuevo, una vez más no entiendo por qué, ya que no debería, pero simplemente lo desvinculé
3. Nginx no hace automáticamente el enlace simbólico para los sitios disponibles a habilitados para el sitio.

Espero que esto le ahorre a alguien algunos problemas!

Tuve el mismo problema con un nuevo nginx (v1.8). Las versiones más nuevas recomiendan usar en snippets/fastcgi-php.conf;lugar de fastcgi.conf. Entonces, si copia / pega include fastcgi.confdesde un tutorial, puede terminar con el Primary script unknownerror en el registro.

"El script primario desconocido" es causado por el contexto de seguridad de SELinux.

el cliente recibe la respuesta

Archivo no encontrado.

nginx error.log tiene el siguiente mensaje de error

* 19 FastCGI enviado en stderr: "Se desconoce la secuencia de comandos primaria" al leer el encabezado de respuesta desde el nivel superior

así que simplemente cambie el tipo de contexto de seguridad de la carpeta raíz web a httpd_sys_content_t

chcon -R -t httpd_sys_content_t /var/www/show

hay 3 usuarios para la configuración nginx / php-fpm

/etc/nginx/nginx.conf

user nobody nobody;  ### `user-1`, this is the user run nginx woker process
...
include servers/*.conf;

/etc/nginx/conf.d/www.conf

location ~ \.php$ {
#   fastcgi_pass 127.0.0.1:9000;  # tcp socket
    fastcgi_pass unix:/var/run/php-fpm/fpm-www.sock;  # unix socket
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

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

[www]
user = apache  ### `user-2`, this is the user run php-fpm pool process
group = apache

;listen = 127.0.0.1:9000  # tcp socket
listen = /var/run/php-fpm/fpm-www.sock  # unix socket

listen.onwer = nobody  ### `user-3`, this is the user for unix socket, like /var/run/php-fpm/fpm-www.sock
listen.group = nobody  # for tcp socket, these lines can be commented
listen.mode = 0660

user-1 y user-2 no son necesarios para ser lo mismo.

para el socket de Unix, el usuario-1 debe ser el mismo que el usuario-3, ya que nginx fastcgi_pass debe tener permiso de lectura / escritura en el socket de Unix.

de lo contrario, nginx obtendrá 502 Bad Gateway y nginx error.log tiene el siguiente mensaje de error

* 36 connect () a unix: /var/run/php-fpm/fpm-www.sock falló (13: Permiso denegado) mientras se conectaba en sentido ascendente

y el usuario / grupo de la carpeta raíz web (/ var / www / show) no es necesario que sea el mismo que cualquiera de estos 3 usuarios.

También tuve este problema y lo resolví intercambiando las líneas include fastcgi_paramsy fastcgi_param SCRIPT_FILENAME ....

De hecho, nginx establece el último valor de cada parámetro FastCGI, por lo que debe colocar su valor después del valor predeterminado incluido en fastcgi_params.

Resolví este problema cerrando SELINUX en el sistema CentOS7.3

pasos:

• ejecutivo setenforce 0
• U también necesita modificar el archivo de configuración

vim /etc/selinux/config set SELINUX to disabled

Encontré su pregunta buscando el mismo mensaje de error pero usando apache + php-fpm (sin nginx). Para mí, el problema era una barra oblicua en el lugar equivocado: muchas sugerencias de configuración incluyen una línea del formulario:

SetHandler "proxy:unix:/path/to/file.socket|fcgi://localhost/:9000"

Al colocar la última barra después del número de puerto de esta manera:

SetHandler "proxy:unix:/path/to/file.socket|fcgi://localhost:9000/"

El problema desapareció para mí. Quizás puedas hacer algo similar

Me encuentro con la misma pregunta, ¡pero otro método no me ayudó a resolver la pregunta!

Lo resuelvo, encuentro que la clave es que: El derecho de usuario de Linux lleva a la pregunta: FastCGI enviado en stderr: "Script primario desconocido"

Porque el usuario predeterminado de PHP-FPM: group es apache: apache, pero su directorio de código es someBody: someBody. ¡Entonces debería cambiar el derecho de usuario!

Escribo un blog para resolver esta pregunta. Puedes ver este blog:

[Nginx FastCGI enviado en stderr: "Script primario desconocido"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

Cloné un sitio remoto, y el wp-config.php ya existente tenía la información de la base de datos del servidor remoto.

Resolví este problema configurando mi configuración local de WordPress, con la información de mi base de datos local.

Hice todo desde arriba, perdí 2 horas golpeándome la cabeza y el problema persistió. Finalmente hice:

sudo service php7.0-fpm restart

Y viola funcionó!

Por cierto, estaba configurando un nuevo proyecto de Symfony 3.4 con nginx conf desde el enlace: https://symfony.com/doc/3.4/setup/web_server_configuration.html

Esa fue la quinta vez que comencé un nuevo proyecto de Symfony y no podía creer que este "Script primario desconocido" estuviera sucediendo.

Verifique los permisos para su archivo de calcetines php-fpm, de alguna manera no fue accesible:

chmod 755 /usr/local/var/run/php-fpm.sock

luego intente reiniciar nginx.

Este mensaje extraño me ha atrapado durante mucho tiempo. No estoy seguro de la causa porque todo funcionó por un tiempo y de repente dejó de funcionar.

Estaba acortando las URL de wiki según lo prescrito por MediaWiki, con Bitnami / Nginx en Lightsail.

Busqué y leí muchas publicaciones, esta parece resumir todos los escenarios posibles, y los probé todos:

• nginx está bien, la carpeta raíz php está funcionando, la subcarpeta no está funcionando
• error arrojado como 404 + una cadena desnuda "Archivo no encontrado", no por nginx
• agregar rootal servidor, no funcionó
• verifique los permisos de las carpetas y php-fpm / nginx, no hay problema, la raíz y las subcarpetas son las mismas
• consulte el manual de php-fpm para la interpretación del código de error, no pude encontrar uno
• active el registro de acceso php-fpm, encontró que el URI de solicitud era correcto, pero se devuelve 404
• intente activar el modo detallado / depuración para php-fpm, no funcionó, el supuesto archivo de registro de errores siempre está vacío

Así que tenía que probar el último recurso, a partir de PHP carpeta raíz estaba funcionando y subcarpetas no lo fuera, la única diferencia importante entre ellos aparte rootes la carpeta raíz utilizada $request_filenamey de la subcarpeta lugares utilizados $document_rooty $fastcgi_script_name, por lo que cambió la configuración de ubicación subcarpeta para que coincidan con los de la carpeta raíz.

Luego funcionó ... Todavía no estoy seguro de por qué funcionó. Porque cuando reviso el registro de acceso php-fpm veo el mismo URI, uno era 404 y el otro 200.

La única diferencia estaba en la configuración. Como producen la misma salida, no sé por qué el resultado fue diferente.

De todos modos, decidí publicar mis 2 centavos aquí, espero que esto ayude.

PD: Realmente espero que PHP proporcione mejores mensajes de error y un modo detallado, porque esto es realmente frustrante al no poder aislar el problema y no hay forma de ver información detallada de salida y depuración.

Intente agregar la directiva raíz dentro de su ubicación php.

location ~ \.php {
      root /home/willem/git/console/www;
      ...
}