Nginx 1 FastCGI envoyé dans stderr: "Script principal inconnu"

Ma première utilisation de Nginx, mais je suis plus que familier avec Apache et Linux. J'utilise un projet existant et chaque fois que j'essaie de voir l'index.php, je reçois un fichier 404 non trouvé.

Voici l'entrée 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"

Et voici le fichier des sites 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;
    }
}

Mon / home / willem / git / console appartient à www-data: www-data (mon utilisateur web qui exécute php, etc.) et je lui ai donné 777 autorisations par frustration ...

Ma meilleure hypothèse est que quelque chose ne va pas avec la configuration, mais je ne peux pas le comprendre ...

UPDATE Je l'ai donc déplacé /var/www/et utilisé une configuration beaucoup plus basique:

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;
    }

}

De plus, si j'appelle, localhost/console/frontend/www/index.phpje reçois 500 PHP, ce qui signifie qu'il sert là-bas. Il ne sert simplement pas hors console.ordercloud ...

Le message d'erreur «script principal inconnu» est presque toujours lié à un paramètre mal défini SCRIPT_FILENAMEdans la fastcgi_paramdirective nginx (ou à des autorisations incorrectes, voir autres réponses).

Vous utilisez un ifdans la configuration que vous avez posté en premier. Eh bien, il faut bien savoir maintenant que si c’est le mal et produit souvent des problèmes.

Définir la rootdirective dans un bloc de localisation est une mauvaise pratique, bien sûr que cela fonctionne.

Vous pouvez essayer quelque chose comme ce qui suit:

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;
    }
}

Veuillez noter que la configuration ci-dessus n'a pas été testée. nginx -tAvant de l’appliquer, exécutez- le pour rechercher les problèmes que nginx peut détecter immédiatement.

Ce n'est pas toujours que le SCRIPT_FILENAMEsoit faux.
Il se peut également que PHP fonctionne avec le mauvais utilisateur / groupe .

Cet exemple est spécifique à Mac OS X , qui, selon mon expérience, est le plus fastidieux à configurer (Debian est simple en comparaison). Je viens de passer de PHP 5.6 à 7.0 en utilisant homebrew et les excellents paquets josegonzalez.

Le problème était qu'une nouvelle copie des fichiers de configuration avait été créée.

Le fichier de configuration principal est /usr/local/etc/php/7.0/php-fpm.conf, mais notez la section Définitions du pool à la fin où elle inclut un sous-répertoire complet.

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

Dans php-fpm.dil y a un www.conffichier. Par défaut, cela a:

user = _www
group = _www

Sous OS X, vous devrez peut-être modifier cela pour:

user = [your username]
group = staff

(vous devriez trouver cela correspond à une ls -lhde vos racines document_root)

Malheureusement, sans cette modification, vous verrez toujours cela dans votre journal des erreurs Nginx même s'il recherche le fichier au bon endroit .

"Primary script unknown" while reading response header from upstream

Vérifiez ce qu'il fonctionne actuellement en tant que:

ps aux | grep 'php-fpm'

ou plus proprement:

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

Comment vérifier si le nom de fichier du script est correct:

(volé à igorsantos07 dans l'autre réponse)

Ajouter au httpbloc de main /usr/local/etc/nginx/nginx.conf:

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

(où le premier bit doit être celui que vous utilisez actuellement, pour que vous puissiez voir s'il est correct.)

Et pour utiliser le journal que vous venez de définir, dans le serverbloc de votre site :

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

Si c'est correct, demander à example.com/phpinfo.php produira quelque chose comme ceci:

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

Pouvez-vous simplifier votre configuration existante?

Utilisez-vous un location ~ \.php {bloc que vous avez copié / collé à partir d’internet? La plupart des forfaits vous permettent de le faire plus rapidement et proprement. Par exemple, sur OS X, vous avez juste besoin de ceci:

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

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

Des éléments tels que fastcgi_split_path_info, try_files et fastcgi_index (par défaut, index.php) sont présents /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Cela inclut à son tour /usr/local/etc/nginx/fastcgi.confune liste de fastcgi_paramparamètres, notamment l’essentiel SCRIPT_FILENAME.

Ne dupliquez jamais rootdans le bloc d'emplacement PHP.

Ok, donc 3 choses que j'ai trouvées après une journée de lutte

1. Pour une raison quelconque j'avais déjà quelque chose en cours d'exécution sur le port 9000 alors je suis passé à 9001
2. Mon site par défaut interceptait mon nouveau site. Encore une fois, je ne comprends pas pourquoi, puisqu'il ne le devrait pas, mais je l'ai simplement dissocié.
3. Nginx ne fait pas automatiquement le lien sym pour les sites disponibles pour les sites activés.

J'espère que cela évite des ennuis à quelqu'un!

Avait le même problème avec un nginx plus récent (v1.8). Les nouvelles versions recommandent d'utiliser snippets/fastcgi-php.conf;au lieu de fastcgi.conf. Donc, si vous copiez / collez à include fastcgi.confpartir d'un tutoriel, vous pourriez vous retrouver avec l' Primary script unknownerreur dans le journal.

"Le script principal est inconnu" est provoqué par le contexte de sécurité SELinux.

le client obtient la réponse

Fichier non trouvé.

nginx error.log a le message d'erreur suivant

* 19 FastCGI envoyé dans stderr: "Script primaire inconnu" lors de la lecture de l'en-tête de la réponse depuis l'amont.

il suffit donc de changer le type de contexte de sécurité du dossier racine Web en httpd_sys_content_t

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

il y a 3 utilisateurs pour la configuration 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 et user-2 ne sont pas nécessairement identiques.

pour un socket Unix, user-1 doit être identique à user-3, car nginx fastcgi_pass doit disposer des droits de lecture / écriture sur le socket Unix.

sinon nginx obtiendra 502 passerelle incorrecte et nginx error.log a le message d'erreur suivant

* 36 connect () à unix: /var/run/php-fpm/fpm-www.sock a échoué (13: autorisation refusée) lors de la connexion à l'amont

et l'utilisateur / le groupe du dossier racine Web (/ var / www / show) ne doit pas nécessairement être identique à l'un de ces 3 utilisateurs.

J'ai eu ce problème aussi, et je l'ai résolu en échangeant les lignes include fastcgi_paramset fastcgi_param SCRIPT_FILENAME ....

En effet, nginx définit la dernière valeur de chaque paramètre FastCGI, vous devez donc placer votre valeur après la valeur par défaut incluse dans fastcgi_params.

J'ai résolu ce problème en fermant SELINUX dans le système CentOS7.3

pas:

• exec setenforce 0
• U également besoin de modifier le fichier de configuration

vim /etc/selinux/config set SELINUX to disabled

J'ai trouvé votre question cherchant le même message d'erreur mais utilisant apache + php-fpm (no nginx). Pour moi, le problème était une barre oblique au mauvais endroit: de nombreuses suggestions d'installation incluent une ligne de la forme suivante:

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

En plaçant la dernière barre oblique après le numéro de port comme suit:

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

le problème a disparu pour moi. Peut-être que vous pouvez faire quelque chose de similaire

Je rencontre la même question, mais une autre méthode ne m'a pas aidé à résoudre la question!

Je résous le problème, je trouve que la clé est la suivante: Le droit d'utilisateur Linux conduit à la question: FastCGI envoyé dans stderr: "Script primaire inconnu"

Parce que l'utilisateur par défaut de PHP-FPM: groupe est apache: apache, mais votre code dir est someBody: someBody. Donc, vous devriez changer le droit d'utilisateur!

J'écris un blog pour résoudre cette question, vous pouvez voir ce blog:

[Nginx FastCGI a envoyé dans stderr: "Le script principal est inconnu"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

J'ai cloné un site distant et le fichier wp-config.php déjà existant contenait les informations de la base de données du serveur distant.

J'ai résolu ce problème en configurant ma configuration wordpress locale avec les informations de ma base de données locale.

J'ai tout fait d'en haut, j'ai perdu 2 heures en me cognant la tête et le problème persistait. Enfin j'ai fait:

sudo service php7.0-fpm restart

Et l'alto a fonctionné!

Au fait, je préparais un nouveau projet symfony 3.4 avec nginx conf à partir de link: https://symfony.com/doc/3.4/setup/web_server_configuration.html

C'était la cinquième fois que je débutais un nouveau projet Symfony et je ne pouvais pas croire que ce "script primaire inconnu" se produise.

Vérifiez les autorisations pour votre fichier chaussette php-fpm, en quelque sorte, il n'était pas accessible:

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

puis essayez de redémarrer nginx.

Je suis pris au piège par ce message étrange depuis très longtemps. Je ne suis pas sûr de la cause, parce que tout a fonctionné pendant un moment, puis a soudain cessé de fonctionner.

Je raccourcissais les URL du wiki comme prescrit par MediaWiki, avec Bitnami / Nginx sur Lightsail.

Recherché et lu de nombreux articles, celui-ci semble résumer tous les scénarios possibles et je les ai tous essayés:

• nginx va bien, le dossier racine php fonctionne, le sous-dossier n’est pas
• erreur renvoyée en tant que 404 + une chaîne nue "Fichier non trouvé", pas par nginx
• ajouter rootau serveur, ne fonctionne pas
• vérifier les permissions des dossiers et de php-fpm / nginx, aucun problème de racine et les sous-dossiers ne sont identiques
• vérifiez le manuel php-fpm pour l'interprétation du code d'erreur, n'a pas pu en trouver
• activer le journal d'accès php-fpm, l'URI de la requête a été trouvé, mais 404 est renvoyé
• essayez d'activer le mode verbose / debug pour php-fpm, cela ne fonctionne pas, le fichier journal d'erreur supposé est toujours vide

Donc , je devais essayer le dernier recours, puisque le dossier racine php fonctionnait et les sous - dossiers n'étaient pas, la seule différence majeure entre elles autres que rootest dossier racine utilisé $request_filenameet emplacements subfolder utilisés $document_rootet $fastcgi_script_name, donc je l' ai changé les paramètres d'emplacement du sous - dossier pour correspondre à ceux du dossier racine.

Ensuite, cela a fonctionné ... Je ne sais toujours pas pourquoi cela a fonctionné. Parce que quand je vérifie le journal d'accès php-fpm, je vois le même URI, l'un était 404 et l'autre 200.

La seule différence était dans la configuration. Comme ils produisent le même résultat, je ne sais pas pourquoi le résultat est sorti différemment.

Quoi qu'il en soit, j'ai décidé de poster mes 2 centimes ici, j'espère que cela aidera.

PS: J'espère vraiment que PHP fournira de meilleurs messages d'erreur et le mode commenté, parce que c'est vraiment frustrant de ne pas pouvoir isoler le problème et qu'il est impossible de voir la sortie détaillée et les informations de débogage.

Essayez d'ajouter une directive racine dans votre emplacement php.

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