Nginx 1 FastCGI gesendet in stderr: "Primäres Skript unbekannt"

Ich habe Nginx zum ersten Mal benutzt, bin aber mit Apache und Linux mehr als vertraut. Ich verwende ein bestehendes Projekt und wenn ich jemals versuche, die index.php zu sehen, erhalte ich eine 404-Datei, die nicht gefunden wurde.

Hier ist der access.log-Eintrag:

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"

Und hier ist die für Websites verfügbare Datei:

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

Mein / home / willem / git / console gehört www-data: www-data (mein Webbenutzer, der PHP ausführt, usw.) und ich habe ihm aus Frustration 777 Berechtigungen erteilt ...

Ich vermute, dass etwas mit der Konfiguration nicht stimmt, aber ich kann es nicht herausfinden ...

UPDATE Also habe ich es verschoben /var/www/und eine viel grundlegendere Konfiguration verwendet:

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

}

Auch wenn ich anrufe, localhost/console/frontend/www/index.phpbekomme ich 500 PHP, was bedeutet, dass es dort dient. Es dient nur nicht von console.ordercloud ...

Die Fehlermeldung "Primäres Skript unbekannt" bezieht sich fast immer auf eine falsche Einstellung SCRIPT_FILENAMEin der Nginx- fastcgi_paramDirektive (oder auf falsche Berechtigungen, siehe andere Antworten).

Sie verwenden eine ifin der Konfiguration, die Sie zuerst gepostet haben. Nun, es sollte inzwischen bekannt sein, dass wenn böse ist und oft Probleme erzeugt.

Das Setzen der rootDirektive innerhalb eines Location Blocks ist eine schlechte Praxis, es funktioniert natürlich.

Sie können Folgendes ausprobieren:

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

Bitte beachten Sie, dass die obige Konfiguration nicht getestet wurde. Sie sollten es ausführen, nginx -tbevor Sie es anwenden, um zu prüfen, ob Probleme vorliegen, die nginx sofort erkennen kann.

Es ist nicht immer so, dass das SCRIPT_FILENAMEfalsch ist.
Es kann auch sein, dass PHP als der falsche Benutzer / die falsche Gruppe ausgeführt wird .

Dieses Beispiel ist spezifisch für Mac OS X , das meiner Erfahrung nach am schwierigsten einzurichten ist (Debian ist vergleichsweise einfach). Ich habe gerade ein Upgrade von PHP 5.6 auf 7.0 mit Homebrew und den hervorragenden josegonzalez-Paketen durchgeführt.

Das Problem war, dass eine neue Kopie der Konfigurationsdateien erstellt wurde.

Die Hauptkonfigurationsdatei ist /usr/local/etc/php/7.0/php-fpm.conf, aber beachten Sie den Abschnitt " Pooldefinitionen " am Ende, in dem ein ganzes Unterverzeichnis enthalten ist.

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

In php-fpm.dgibt es eine www.confDatei. Standardmäßig hat dies:

user = _www
group = _www

Unter OS X müssen Sie möglicherweise Folgendes ändern:

user = [your username]
group = staff

(Sie sollten feststellen, dass dies mit einem ls -lhIhrer document_root übereinstimmt. )

Leider wird dies ohne diese Änderung auch dann in Ihrem Nginx-Fehlerprotokoll angezeigt , wenn die Datei an der richtigen Stelle gesucht wird .

"Primary script unknown" while reading response header from upstream

Überprüfen Sie, wie es aktuell ausgeführt wird:

ps aux | grep 'php-fpm'

oder sauberer:

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

So überprüfen Sie, ob der Dateiname des Skripts korrekt ist:

(gestohlen von igorsantos07 in der anderen Antwort)

Zum httpHauptblock hinzufügen /usr/local/etc/nginx/nginx.conf:

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

(Wo das erste Bit sein muss, was auch immer Sie gerade verwenden, damit Sie sehen können, ob es richtig ist.)

Um das soeben definierte Protokoll im serverBlock Ihrer Site zu verwenden, gehen Sie wie folgt vor:

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

Wenn es korrekt ist, wird das Anfordern von example.com/phpinfo.php ungefähr so ​​aussehen:

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

Können Sie Ihre bestehende Konfiguration vereinfachen?

Verwenden Sie einen location ~ \.php {Block, den Sie aus dem Internet kopiert / eingefügt haben? Mit den meisten Paketen können Sie dies schneller und sauberer erledigen. zB unter OS X brauchst du jetzt nur noch folgendes:

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

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

Dinge wie fastcgi_split_path_info, try_files und fastcgi_index (standardmäßig index.php) sind in /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Dies beinhaltet wiederum /usr/local/etc/nginx/fastcgi.confeine Liste von fastcgi_paramEinstellungen, einschließlich des entscheidenden SCRIPT_FILENAME.

Duplizieren Sie niemals rootim PHP-Adressblock.

Ok, also 3 Dinge, die ich nach einem Tag voller Schwierigkeiten gefunden habe

1. Aus irgendeinem Grund lief auf Port 9000 bereits etwas, und ich wechselte zu 9001
2. Meine Standard-Site hat meine neue abgefangen. Ich verstehe wieder nicht, warum, da dies nicht der Fall sein sollte, aber ich habe die Verknüpfung einfach aufgehoben
3. Nginx führt den Sym-Link für Sites, die für Sites verfügbar sind, nicht automatisch aus.

Hoffe, das erspart jemandem Ärger!

Hatte das gleiche Problem mit einem neueren Nginx (v1.8). Neuere Versionen empfehlen snippets/fastcgi-php.conf;statt fastcgi.conf. Wenn Sie also include fastcgi.confaus einem Lernprogramm kopieren / einfügen , wird möglicherweise der Primary script unknownFehler im Protokoll angezeigt.

"Primäres Skript unbekannt" wird durch den SELinux-Sicherheitskontext verursacht .

Client erhalten die Antwort

Datei nicht gefunden.

nginx error.log hat die folgende Fehlermeldung

* 19 FastCGI gesendet in stderr: "Primäres Skript unbekannt" beim Lesen des Antwortheaders vom Upstream

Ändern Sie einfach den Sicherheitskontexttyp des Webstammordners in httpd_sys_content_t

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

Es gibt 3 Benutzer für nginx / php-fpm config

/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

Benutzer-1 und Benutzer-2 müssen nicht identisch sein.

Für Unix- Sockets muss Benutzer-1 mit Benutzer-3 identisch sein , da nginx fastcgi_pass über Lese- / Schreibrechte für den Unix-Socket verfügen muss.

Andernfalls erhält nginx 502 Bad Gateway und nginx error.log hat die folgende Fehlermeldung

* 36 connect () to unix: /var/run/php-fpm/fpm-www.sock fehlgeschlagen (13: Berechtigung verweigert), während eine Verbindung zum Upstream hergestellt wurde

und der Benutzer / die Gruppe des Webstammordners (/ var / www / show) muss nicht mit einem dieser 3 Benutzer identisch sein.

Ich hatte auch dieses Problem und löste es, indem ich die Zeilen include fastcgi_paramsund vertauschte fastcgi_param SCRIPT_FILENAME ....

In der Tat setzt nginx den letzten Wert jedes FastCGI-Parameters, so dass Sie Ihren Wert nach dem in fastcgi_params enthaltenen Standardwert setzen müssen.

Ich habe dieses Problem gelöst, indem ich SELINUX im CentOS7.3-System geschlossen habe

Schritte:

• exec setenforce 0
• Sie müssen auch die Konfigurationsdatei ändern

vim /etc/selinux/config set SELINUX to disabled

Ich fand Ihre Frage nach der gleichen Fehlermeldung suchend, aber Apache + php-fpm (kein nginx) verwendend. Für mich war das Problem ein Schrägstrich an der falschen Stelle: Viele Einrichtungsvorschläge enthalten eine Zeile der Form:

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

Durch Platzieren des letzten Schrägstrichs nach der Portnummer wie folgt:

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

Das Problem verschwand für mich. Vielleicht können Sie etwas Ähnliches tun

Ich treffe die gleiche Frage, aber eine andere Methode hat mir nicht geholfen, die Frage zu lösen!

Ich löse es, ich finde den Schlüssel ist, dass: Linux User Right zu der Frage führen: FastCGI in stderr gesendet: "Primärskript unbekannt"

Weil die PHP-FPM-Standardgruppe user: group apache: apache lautet. Ihr Code-Verzeichnis lautet jedoch someBody: someBody. Also solltest du das Userrecht ändern!

Ich schreibe ein Blog, um diese Frage zu lösen. Sie können dieses Blog sehen:

[Nginx FastCGI gesendet in stderr: "Primäres Skript unbekannt"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

Ich habe eine Remote-Site geklont, und die bereits vorhandene Datei wp-config.php enthielt die Informationen zur Remote-Server-Datenbank.

Ich habe dieses Problem behoben, indem ich meine lokale WordPress-Konfiguration mit meinen lokalen Datenbankinformationen eingerichtet habe.

Ich tat alles von oben, verlor 2 Stunden meinen Kopf und das Problem blieb bestehen. Endlich habe ich gemacht:

sudo service php7.0-fpm restart

Und Viola hat es geklappt!

Übrigens habe ich ein neues Symfony 3.4-Projekt mit nginx conf über den folgenden Link eingerichtet: https://symfony.com/doc/3.4/setup/web_server_configuration.html

Es war mein fünftes Mal, dass ich ein neues Symfony-Projekt gestartet habe, und ich konnte nicht glauben, dass dieses "Primärskript unbekannt" passiert.

Überprüfen Sie die Berechtigungen für Ihre PHP-FPM-SOCK-Datei, auf die irgendwie nicht zugegriffen werden konnte:

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

Versuchen Sie dann, nginx neu zu starten.

Ich bin schon sehr lange in dieser seltsamen Botschaft gefangen. Ich bin mir über die Ursache nicht sicher, weil alles eine Weile funktionierte und dann plötzlich aufhörte zu arbeiten.

Ich habe Wiki-URLs verkürzt, wie von MediaWiki vorgeschrieben, mit Bitnami / Nginx auf Lightsail.

Durchsucht und gelesen viele Beiträge, dieser scheint alle möglichen Szenarien zusammenzufassen, und ich habe sie alle ausprobiert:

• Nginx ist in Ordnung, Root-Ordner PHP funktioniert, Unterordner nicht
• Fehler als 404 + eine leere Zeichenfolge "Datei nicht gefunden", nicht von Nginx geworfen
• rootzum Server hinzufügen , hat nicht funktioniert
• Überprüfen Sie die Berechtigungen von Ordnern und PHP-Fpm / Nginx, kein Problem root und Unterordner sind die gleichen
• Überprüfen Sie das php-fpm-Handbuch auf Fehlercode-Interpretation. Konnte keinen finden
• Aktivieren Sie das PHP-FPM-Zugriffsprotokoll, und stellen Sie fest, dass der Anforderungs-URI korrekt ist. Es wird jedoch 404 zurückgegeben
• versuche den verbose / debug mode für php-fpm einzuschalten, habe nicht funktioniert, die angebliche fehlerprotokolldatei ist immer leer

Also musste ich den letzten Ausweg versuchen, da der Root-Ordner PHP funktionierte und Unterordner nicht, der einzige große Unterschied zwischen ihnen, abgesehen vom verwendeten rootRoot-Ordner $request_filenameund den verwendeten Unterordnerpositionen, $document_rootund $fastcgi_script_nameso änderte ich die Unterordnerpositionseinstellungen, um sie mit denen des Root-Ordners abzugleichen.

Dann hat es funktioniert ... Ich bin mir immer noch nicht sicher, warum es funktioniert hat. Denn wenn ich das PHP-FPM-Zugriffsprotokoll überprüfe, sehe ich die gleiche URI, eine war 404 und die andere war 200.

Der einzige Unterschied bestand in der Konfiguration. Da sie die gleiche Ausgabe produzieren, weiß ich nicht, warum das Ergebnis anders ausfiel.

Trotzdem habe ich beschlossen, meine 2 Cent hier zu posten, hoffe das hilft.

PS: Ich hoffe wirklich, dass PHP bessere Fehlermeldungen und einen ausführlichen Modus bietet, da dies sehr frustrierend ist, das Problem nicht eingrenzen zu können und keine Möglichkeit zu haben, ausführliche Ausgabe- und Debug-Informationen zu erhalten.

Versuchen Sie, die root-Direktive in Ihren PHP-Speicherort einzufügen.

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