127 votes

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

Ma première fois en utilisant 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 index.php je reçois une erreur 404 Fichier non trouvé.

Voici l'entrée du fichier access.log:

2013/06/19 16:23:23 [error] 2216#0: *1 FastCGI a envoyé dans stderr : "Script principal inconnu" lors de la lecture de l'en-tête de réponse en amont, client : 127.0.0.1, serveur : localhost, requête : "GET /index.php HTTP/1.1", en amont : "fastcgi://127.0.0.1:9000", hôte : "www.ordercloud.lh"

Et voici le fichier sites-available:

serveur {
    définit $chemin_hôte "/home/willem/git/console/www";
    access_log  /www/logs/console-access.log  main;

    server_name  console.ordercloud;
    root   $chemin_hôte/htdocs;
    définit $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) {
        refuse  all;
    }

    #éviter le traitement des appels aux fichiers statiques inexistants par yii
    location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
        try_files $uri =404;
    }

    # faire passer les scripts PHP au serveur FastCGI écoutant sur 127.0.0.1:9000
    #
    location ~ \.php {
        fastcgi_split_path_info  ^(.+\.php)(.*)$;

        #laisser yii intercepter les appels aux fichiers PHP inexistants
        définit $fsn /$yii_bootstrap;
        si (-f $document_root$fastcgi_script_name){
            définit $fsn $fastcgi_script_name;
        }

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

        #PATH_INFO et PATH_TRANSLATED peuvent être omis, mais RFC 3875 les spécifie pour CGI
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        fastcgi_param  PATH_TRANSLATED  $document_root$fsn;
    }

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

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

Mon meilleur pari est qu'il y a quelque chose qui ne va pas avec la configuration, mais je ne peux pas le comprendre...

MISE À JOUR Donc je l'ai déplacé à /var/www/ et utilisé une configuration beaucoup plus basique:

serveur {
    #écoute   80; ## écoute pour ipv4 ; cette ligne est par défaut et implicite
    #écoute   [::]:80 ipv6 seulement par défaut = activé ; ## écoute pour ipv6

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

    #Rendre le site accessible depuis 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;
        refuse all;
    }

}

Aussi si j'appelle localhost/console/frontend/www/index.php je reçois un 500 PHP ce qui signifie qu'il est servi là. Il ne sert tout simplement pas à partir de console.ordercloud...

0 votes

Une autre cause possible : Si vous utilisez php-fpm, assurez-vous que l'utilisateur défini dans /etc/php-fpm.d/www.conf a les autorisations nécessaires pour exécuter le script. Je pense que par défaut, il est défini sur apache.

0 votes

Une autre cause possible est que votre SElinux est activé, vérifiez la configuration SElinux et désactivez-le.

0 votes

Je viens de passer ma configuration d'hébergement de FCGId (exécuté en tant que propriétaire de serveur virtuel) à FPM (exécuté en tant que propriétaire de serveur virtuel). En plus d'installer PhP 7.2-fpm, cli et plus encore ...

5voto

ermacmkx Points 109

J'ai tout essayé ci-dessus, j'ai perdu 2 heures à me cogner la tête et le problème persistait toujours. Finalement, j'ai fait :

sudo service php7.0-fpm restart

Et voilà, ça a fonctionné !

Par ailleurs, je mettais en place un nouveau projet symfony 3.4 avec la configuration nginx à 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 n'arrivais pas à croire que ce "script principal inconnu" se produisait.

1 votes

Réponse très sous-estimée. J'ai passé une journée à essayer presque toutes les solutions suggérées, et je n'aurais pas cru qu'il suffisait de redémarrer PHP pour corriger l'erreur.

3voto

Kent Points 31

J'ai résolu ce problème en désactivant SELINUX dans le système CentOS 7.3

étapes:

  • exec setenforce 0
  • Vous devez également modifier le fichier de configuration

vim /etc/selinux/config définir SELINUX sur désactivé

2voto

Seb35 Points 240

J'ai également rencontré 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 placer votre valeur après la valeur par défaut incluse dans fastcgi_params.

1voto

Paco Points 6156

Essayez d'ajouter la directive root à l'intérieur de votre emplacement php.

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

1 votes

La directive root doit être définie sur une base de serveur et ne doit pas être utilisée au sein de blocs de location (sauf si vous êtes un professionnel et que vous voulez contourner certains bugs très spéciaux de nginx dans votre configuration).

1 votes

@Fleshgrinder un seul root par serveur n'est pas une bonne pratique.

0 votes

1voto

spetsnaz Points 111

Vérifiez les autorisations pour votre fichier sock php-fpm, apparemment il n'était pas accessible :

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

puis essayez de redémarrer nginx.

0 votes

Aussi, veillez à vérifier si l'utilisateur php-fpm appartient au groupe nginx. Par exemple, sudo usermod -a -G www-data php-fpm si nginx s'exécute en tant que www-data et que php-fpm s'exécute en tant que php-fpm.

3 votes

Ne vous utilisez pas cette méthode, vous introduisez essentiellement un problème de sécurité ici. La commande dans la réponse donne à tout le monde un accès en lecture et en écriture au socket.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X