it-swarm.com.de

Nginx 1 FastCGI gesendet in stderr: "Primärskript unbekannt"

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

Hier ist der Eintrag 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"

Und hier ist die Site-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 führt PHP usw. aus) 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 auf /var/www/ verschoben 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 localhost/console/frontend/www/index.php Rufe, erhalte ich eine 500 PHP, was bedeutet, dass es dort dient. Es wird einfach nicht außerhalb der Konsole bereitgestellt. Ordercloud ...

85
We0

Ok, also 3 Dinge, die ich nach einem Tag voller Kämpfe gefunden habe

  1. Aus irgendeinem Grund lief auf Port 9000 bereits etwas, also wechselte ich 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 Websites, die für Websites verfügbar sind, nicht automatisch aus.

Hoffe das erspart jemandem Ärger!

8
We0

Die Fehlermeldung "Primärskript unbekannt" bezieht sich fast immer auf ein falsch gesetztes SCRIPT_FILENAME im Nginx fastcgi_param Direktive (oder falsche Berechtigungen, siehe andere Antworten).

Sie verwenden ein if in der Konfiguration, die Sie zuerst veröffentlicht haben. Nun, es sollte inzwischen bekannt sein, dass wenn es böse ist und oft Probleme verursacht.

Das Festlegen der Direktive root innerhalb eines Standortblocks ist eine schlechte Praxis, natürlich funktioniert es.

Sie könnten 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 nginx -t ausführen, bevor Sie es anwenden, um nach Problemen zu suchen, die nginx sofort erkennen kann.

96
Fleshgrinder

Es ist nicht immer , dass der SCRIPT_FILENAME Falsch ist.
Es kann auch sein, dass PHP als falscher Benutzer/falsche Gruppe ausgeführt wird .

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

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

Die Hauptkonfigurationsdatei ist /usr/local/etc/php/7.0/php-fpm.conf. Beachten Sie jedoch den Abschnitt Pooldefinitionen am Ende, in dem sich ein ganzes Unterverzeichnis befindet.

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

In php-fpm.d Gibt es eine www.conf - Datei. Standardmäßig hat dies:

user = _www
group = _www

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

user = [your username]
group = staff

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

Ohne diese Änderung wird dies leider immer noch in Ihrem Nginx-Fehlerprotokoll angezeigt, auch 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 Skriptdateiname korrekt ist:

(gestohlen von igorsantos07 in der anderen Antwort)

Zum http Block von main /usr/local/etc/nginx/nginx.conf Hinzufügen:

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

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

Und um das soeben definierte Protokoll im Block server Ihrer Site zu verwenden:

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

Wenn es korrekt ist, führt das Anfordern von example.com/phpinfo.php zu folgendem Ergebnis:

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

Können Sie Ihre vorhandene Konfiguration vereinfachen?

Verwenden Sie einen location ~ \.php { Block, den Sie von irgendwo außerhalb des Internets kopiert/eingefügt haben? Mit den meisten Paketen können Sie dies schneller und sauberer tun. z.B. Unter OS X brauchen Sie 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) befinden sich in /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Dazu gehört wiederum /usr/local/etc/nginx/fastcgi.conf, Eine Liste von fastcgi_param - Einstellungen, einschließlich des entscheidenden SCRIPT_FILENAME.

Duplizieren Sie niemals root im Standortblock PHP).

45
William Turrell

Hatte das gleiche Problem mit einem neueren Nginx (v1.8). Neuere Versionen empfehlen die Verwendung von snippets/fastcgi-php.conf; Anstelle von fastcgi.conf. Wenn Sie also include fastcgi.conf Aus einem Lernprogramm kopieren/einfügen, wird möglicherweise der Fehler Primary script unknown Im Protokoll angezeigt.

6
Dan Dascalescu

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

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 die Konfiguration von 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

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

für Unix-Socket muss Benutzer-1 mit Benutzer-3 identisch sein, da nginx fastcgi_pass Lese-/Schreibberechtigung für den Unix-Socket haben 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) beim Herstellen einer Verbindung zum Upstream

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

4
PLA

Ich hatte auch dieses Problem und löste es durch Austausch der Zeilen include fastcgi_params und fastcgi_param SCRIPT_FILENAME ....

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

2
Seb35

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

1
kent

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

Sudo service php7.0-fpm restart

Und Bratsche 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

Ich habe zum fünften Mal ein neues Symfony-Projekt gestartet und konnte nicht glauben, dass dieses "unbekannte Primärskript" stattfindet.

0
ermacmkx

Ich bin schon sehr lange von dieser seltsamen Botschaft gefangen. Ich bin mir über die Ursache nicht sicher, weil alles eine Weile funktioniert hat und dann plötzlich aufgehört hat zu funktionieren.

Ich habe die von MediaWiki vorgeschriebenen Wiki-URLs mit Bitnami/Nginx auf Lightsail gekürzt.

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 bloße Zeichenfolge "Datei nicht gefunden", nicht von nginx
  • root zum Server hinzufügen, hat nicht funktioniert
  • überprüfen Sie die Berechtigungen von Ordnern und php-fpm/nginx. Kein Problem. Root und Unterordner sind identisch
  • überprüfen Sie das PHP-Fpm-Handbuch auf Fehlercode-Interpretation, konnte keinen finden
  • aktivieren Sie das PHP-Fpm-Zugriffsprotokoll. Es wurde festgestellt, dass der Anforderungs-URI korrekt war, aber 404 wird zurückgegeben
  • versuche den ausführlichen/debug-Modus für php-fpm einzuschalten, hat nicht funktioniert, die angebliche Fehlerprotokolldatei ist immer leer

Also musste ich den letzten Ausweg versuchen, da der Stammordner PHP funktionierte und die Unterordner nicht. Der einzige große Unterschied zwischen ihnen außer root ist der verwendete Stammordner $request_filename und verwendete Unterordnerpositionen $document_root und $fastcgi_script_name, daher habe ich die Einstellungen für den Speicherort des Unterordners so geändert, dass sie mit denen des Stammordners übereinstimmen.

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 denselben URI, einer war 404 und der andere war 200.

(enter image description here

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

Wie auch immer, ich habe beschlossen, meine 2 Cent hier zu posten, hoffe das hilft.

PS: Ich hoffe wirklich, dass PHP bessere Fehlermeldungen und einen ausführlichen Modus bereitstellen, da dies wirklich frustrierend ist, wenn das Problem nicht eingegrenzt werden kann und keine Möglichkeit besteht, ausführliche Ausgabe- und Debug-Informationen anzuzeigen.

0
Dai

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

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

versuchen Sie dann, Nginx neu zu starten.

0
spetsnaz

Ich habe eine Remote-Site geklont, und die bereits vorhandene Datei wp-config.php enthielt die Datenbankinformationen des Remote-Servers.

Ich habe dieses Problem behoben, indem ich meine lokale wordpress config) mit meinen lokalen Datenbankinformationen eingerichtet habe.

0
Shean Hoxie

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

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

Weil die PHP-FPM-Standardbenutzergruppe: Apache: Apache ist, Ihr Codeverzeichnis jedoch someBody: someBody ist. Sie sollten also das Benutzerrecht ändern!

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

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

0
Love

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

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

Platzieren Sie den letzten Schrägstrich 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

0
Christian

Für mich waren es Erweiterungen.

Mein php-fpm.www.access.log Berichtete:

"GET /index.php5" 404

Die Indexdatei für die Site (MediaWiki) war jedoch index.php. Es stellte sich heraus, dass ich gemischte Erweiterungen (php vs php5) In den relevanten nginx.conf Einträgen hatte. Hier ist eine funktionierende Konfiguration:

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

Sie können alle diese Einträge stattdessen index.php5 Verwenden lassen. Fügen Sie einfach eine index.php5 - Datei mit dem folgenden Inhalt zum Stammverzeichnis hinzu:

<?php require './index.php';

(kein schließendes Tag).

0
vesperto