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 le fichier index.php, j'obtiens un fichier 404 introuvable.
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 disponible sur les sites:
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 exécutant php etc.) et je lui ai donné 777 autorisations par frustration ...
Ma meilleure supposition est que quelque chose ne va pas avec la configuration, mais je ne peux pas le comprendre ...
MISE À JOUR Je l'ai donc déplacé vers /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;
}
}
Aussi, si j'appelle localhost/console/frontend/www/index.php J'obtiens un 500 PHP ce qui signifie qu'il y sert. Il ne sert tout simplement pas hors console.ordercloud ...
Ok, donc 3 choses que j'ai trouvées après une journée de lutte
- Pour une raison quelconque, j'avais déjà quelque chose en cours d'exécution sur le port 9000, je suis donc passé au 9001
- Mon site par défaut interceptait mon nouveau site, encore une fois je ne comprends pas pourquoi car il ne devrait pas, mais je l'ai simplement dissocié
- Nginx ne fait pas automatiquement le lien sym pour les sites accessibles aux sites activés.
J'espère que cela vous évitera quelques ennuis!
Le message d'erreur "script principal inconnu" est presque toujours lié à un SCRIPT_FILENAME mal défini dans le nginx fastcgi_param directive (ou autorisations incorrectes, voir les autres réponses).
Vous utilisez un if dans la configuration que vous avez publiée en premier. Eh bien, il devrait être bien connu maintenant que si c'est mal et produit souvent des problèmes.
Définir la directive root dans un bloc d'emplacement est une mauvaise pratique, bien sûr, cela fonctionne.
Vous pouvez essayer quelque chose comme ceci:
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. Vous devez exécuter nginx -t avant de l'appliquer pour vérifier les problèmes que nginx peut détecter immédiatement.
Ce n'est pas toujours que le SCRIPT_FILENAME est faux.
Il se peut également que PHP fonctionne en tant que mauvais utilisateur/groupe .
Cet exemple est spécifique à Mac OS X , qui selon mon expérience est le plus difficile à configurer (Debian est facile en comparaison) - Je viens de mettre à jour de PHP 5.6 à 7.0, en utilisant homebrew et les excellents packages josegonzalez.
Le problème était qu'une nouvelle copie des fichiers de configuration a été créée.
Le fichier de configuration principal est /usr/local/etc/php/7.0/php-fpm.conf, mais notez la section Définitions de pool à la fin où elle inclut un sous-répertoire entier.
include=/usr/local/etc/php/7.0/php-fpm.d/*.conf
Dans php-fpm.d il y a un www.conf fichier. Par défaut, cela a:
user = _www
group = _www
Sous OS X, vous devrez peut-être modifier ceci pour:
user = [your username]
group = staff
(vous devriez trouver que cela correspond à un ls -lh de votre document_root)
Malheureusement, sans ce changement, vous le verrez toujours 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:
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 http bloc du principal /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, afin que vous puissiez voir s'il est correct.)
Et pour utiliser le journal que vous venez de définir, dans le bloc server 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 { bloquer que vous avez copié/collé depuis un endroit hors d'Internet? La plupart des packages vous permettent de le faire plus rapidement et plus proprement. par exemple. sur OS X, vous avez maintenant 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 choses comme fastcgi_split_path_info, try_files et fastcgi_index (par défaut index.php) sont dans /usr/local/etc/nginx/snippets/fastcgi-php.conf.
Cela comprend à son tour /usr/local/etc/nginx/fastcgi.conf qui est une liste de fastcgi_param paramètres, y compris le SCRIPT_FILENAME crucial.
Ne dupliquez jamais root dans le bloc d'emplacement PHP.
Eu le même problème avec un nginx plus récent (v1.8). Les versions plus récentes recommandent d'utiliser snippets/fastcgi-php.conf; au lieu de fastcgi.conf. Donc, si vous copiez/collez include fastcgi.conf d'un didacticiel, vous pourriez vous retrouver avec le Primary script unknown erreur dans le journal.
"Script principal inconnu" est causé par contexte de sécurité SELinux.
le client obtient la réponse
Fichier non trouvé.
nginx error.log contient le message d'erreur suivant
* 19 FastCGI envoyé dans stderr: "Script primaire inconnu" lors de la lecture de l'en-tête de réponse en 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
l'utilisateur-1 et l'utilisateur-2 ne doivent pas nécessairement être identiques.
pour le socket unix, l'utilisateur-1 doit être le même que l'utilisateur-3, car nginx fastcgi_pass doit avoir une autorisation de lecture/écriture sur le socket unix.
sinon nginx obtiendra 502 Bad Gateway, 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/groupe du dossier racine Web (/ var/www/show) n'est pas nécessairement le même que n'importe lequel de ces 3 utilisateurs.
J'avais aussi ce problème, et je l'ai résolu en échangeant les lignes include fastcgi_params et fastcgi_param SCRIPT_FILENAME ....
En effet, nginx définit la dernière valeur de chaque paramètre FastCGI, vous devez donc mettre 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 - Vous devez également modifier le fichier de configuration
vim /etc/selinux/config set SELINUX to disabled
J'ai tout fait d'en haut, perdu 2 heures à me cogner la tête et le problème persistait. Enfin j'ai fait:
Sudo service php7.0-fpm restart
Et l'alto ça a marché!
Btw, je mettais en place un nouveau projet symfony 3.4 avec nginx conf à partir du lien: https://symfony.com/doc/3.4/setup/web_server_configuration.html
C'était la cinquième fois que je commençais un nouveau projet symfony et je ne pouvais pas croire que ce "script primaire inconnu" se produise.
Je suis piégé par ce message étrange depuis très longtemps. Je ne suis pas sûr de la cause parce que tout a fonctionné pendant un certain temps, puis tout d'un coup a cessé de fonctionner.
Je raccourcissais les URL de wiki comme prescrit par MediaWiki, avec Bitnami/Nginx sur Lightsail.
J'ai cherché 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 comme 404 + une chaîne nue "Fichier introuvable", pas par nginx
- ajouter
rootau serveur, n'a pas fonctionné - vérifier les autorisations des dossiers et php-fpm/nginx, aucun problème racine et sous-dossiers ne sont les mêmes
- vérifier le manuel de php-fpm pour l'interprétation du code d'erreur, impossible d'en trouver un
- activer le journal d'accès php-fpm, a trouvé que l'URI de la demande était correcte, mais 404 est retourné
- essayez d'activer le mode verbeux/de débogage pour php-fpm, n'a pas fonctionné, le fichier journal des erreurs supposé est toujours vide
J'ai donc dû essayer en dernier recours, car le dossier racine php fonctionnait et les sous-dossiers ne l'étaient pas, la seule différence majeure entre eux autre que root est le dossier racine utilisé $request_filename et emplacements des sous-dossiers utilisés $document_root et $fastcgi_script_name, j'ai donc modifié les paramètres d'emplacement des sous-dossiers pour qu'ils correspondent à ceux du dossier racine.
Ensuite, cela a fonctionné ... Je ne sais toujours pas pourquoi cela a fonctionné. Parce que lorsque 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. Puisqu'ils produisent la même sortie, 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 cents ici, j'espère que cela vous aidera.
PS: J'espère vraiment PHP fournit de meilleurs messages d'erreur et un mode détaillé, car cela est vraiment frustrant de ne pas pouvoir isoler le problème et aucun moyen de voir la sortie détaillée et les informations de débogage.
Vérifiez les autorisations pour votre fichier de chaussettes 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.
J'ai cloné un site distant et le 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 locale wordpress, avec mes informations de base de données locale.
Je rencontre la même question, mais une autre méthode ne m'a pas aidé à résoudre la question!
Je le résous, je trouve que la clé est que: Linux User Right mène à la question: FastCGI envoyé dans stderr: "Script primaire inconnu"
Parce que L'utilisateur par défaut PHP-FPM: group est Apache: apache, Mais votre code dir est someBody: someBody. Vous devez donc changer le droit d'utilisateur!
J'écris un blog pour résoudre cette question, vous pouvez voir ce blog:
[Nginx FastCGI envoyé dans stderr: "Script principal inconnu"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary .html
J'ai trouvé votre question à la recherche du même message d'erreur mais en utilisant Apache + php-fpm (pas de nginx). Pour moi, le problème était une barre oblique au mauvais endroit: de nombreuses suggestions de configuration incluent une ligne du formulaire:
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. Vous pouvez peut-être faire quelque chose de similaire
Pour moi, c'était des extensions.
Ma php-fpm.www.access.log signalait:
"GET /index.php5" 404
Pourtant, le fichier d'index du site (MediaWiki) était index.php. Il s'avère que j'avais des extensions mixtes (php vs php5) dans le nginx.conf entrées. Voici une configuration de travail:
location / {
index index.php;
try_files $uri $uri/ = @mediawiki;
}
location = /favicon.ico {
return 204;
}
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /path/to/viki$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT /path/to/viki;
fastcgi_intercept_errors on;
}
location @mediawiki {
rewrite ^/([^?]*)(?:\?(.*))? /index.php?title=$1&$args last;
}
Vous pouvez faire en sorte que toutes ces entrées utilisent index.php5 à la place, ajoutez simplement un index.php5 fichier à la racine avec ce contenu:
<?php require './index.php';
(pas de balise de fermeture).