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

81

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 ...

We0
quelle
Eine weitere mögliche Ursache: Wenn Sie php-fpm verwenden, stellen Sie sicher, dass der in /etc/php-fpm.d/www.conf festgelegte Benutzer über Berechtigungen für das Skript verfügt, das ausgeführt werden soll. Ich denke, es ist standardmäßig Apache.
Dave
Eine weitere mögliche Ursache ist, dass Ihr SElinux aktiviert ist, überprüfen Sie die SElinux-Konfiguration und deaktivieren Sie sie.
CK.Nguyen
Ich habe gerade meine Host-Konfiguration von FCGId (als Eigentümer des virtuellen Servers ausgeführt) auf FPM (als Eigentümer des virtuellen Servers ausgeführt) umgestellt. Zusätzlich zur Installation von PhP 7.2-fpm, cli und mehr ...
PauloBoaventura

Antworten:

92

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.

Fleischwolf
quelle
1
Das löst es für mich; Mir war nicht bewusst, dass du $ document_root voranstellen musstest, ich nahm an, dass dies basierend auf root automatisch geschieht.
b01
3
Wo kann man mehr über die schlechte Praxis des Einstellens des Innenorts erfahren root?
Dan Dascalescu
15
Für diejenigen , die nicht genau wissen , wie die Variable falsch sein könnte: in den Haupt Nginx httpAbschnitt die folgenden: log_format scripts '$document_root$fastcgi_script_name > $request';(oder was auch immer Sie zu SCRIPT_FILENAME Fütterung) und auf Ihre server: access_log /var/log/nginx/scripts.log scripts.
Laden
3
Was ist der yii_bootstrap?
Liebe
43

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.

William Turrell
quelle
2
Sehr schön! war das für mich! Prost Kumpel!
Rollensappletree
Vielen Dank. Für mich hatten die fpm / nginx-Docker-Container, die ich ausgeführt habe, Berechtigungsprobleme beim Zugriff auf diese Ordner.
Tek
@ Fleshgrinders Antwort ist falsch und deine ist richtig! In meinem Fall ging es in der Tat nur darum, den Besitz in der /etc/php/7.0/php-fpm.d/www.confAkte zu korrigieren . Prost, Kumpel. :) Viele weitere Menschen werden dieses Problem möglicherweise auch sehen, da die Beliebtheit von Vagabunden weiter zunimmt.
user392778
/usr/local/etc/nginx/snippets/fastcgi-php.confIch konnte auf meinem Mac nichts finden, aber ich fand/usr/local/etc/nginx/fastcgi.conf
Abbood
Schön!! Kämpfe seit
stunden
7

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!

We0
quelle
Hallo @ we0, ich habe das gleiche Problem mit meinem Setup. Ich habe auch meine andere App auf Port 3001 ausgeführt, daher muss ich meine PHP-App auf Port 3002 hosten. Sie können meinen ursprünglichen Beitrag hier sehen: stackoverflow.com/questions/33229867/… und stackoverflow.com/questions/33409539/… und eine andere ist stackoverflow.com/questions/33519989/… . Hast du irgendeine Idee?
Manish Sapkal
3
Das automatische Bereitstellen von Symlinks von Websites zu Websites, die aktiviert sind, wäre natürlich unerwünscht. Es liegt an Ihnen, diese Symlinks zu erstellen, damit Sie steuern können, welche Websites auf Ihrem Server aktiviert und welche deaktiviert sind.
Erathiel
6

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.

Dan Dascalescu
quelle
4

"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.

PLA
quelle
2

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.

Seb35
quelle
1

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

Kent
quelle
0

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

Christian
quelle
0

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

Liebe
quelle
0

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.

Shean Hoxie
quelle
0

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.

ermacmkx
quelle
0

Ü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.

spetsnaz
quelle
0

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.

Bildbeschreibung hier eingeben

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.

Dai
quelle
-1

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

location ~ \.php {
      root /home/willem/git/console/www;
      ...
}
lg.
quelle
1
Die rootDirektive sollte pro serverBasis gesetzt und nicht in locationBlöcken verwendet werden (es sei denn, Sie sind ein Profi und möchten einige sehr spezielle Nginx-Fehler in Ihrer Konfiguration umgehen).
Fleshgrinder
1
@Fleshgrinder Ein Root pro Server ist keine bewährte Methode.
Garet Claborn
@Fleshgrinder Das sagt nicht der Abschnitt, den Sie verlinkt haben. Das Beispiel für bewährte Verfahren in diesem Abschnitt zeigt eine rootDirektive innerhalb eines locationBlocks.
Ishigoya
@ishigoya Bitte besuchen Sie den Link erneut, die mehreren rootAnweisungen in mehreren locationBlöcken ist eindeutig unter der Überschrift BAD.
Fleischwolf