Nginx 1 FastCGI inviato in stderr: "Script primario sconosciuto"

La prima volta che utilizzo Nginx, ma ho più che familiarità con Apache e Linux. Sto usando un progetto esistente e ogni volta che provo a vedere index.php ottengo un file 404 non trovato.

Ecco la voce 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"

Ed ecco il file disponibile sui siti:

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

La mia / home / willem / git / console è di proprietà di www-data: www-data (il mio utente web che esegue php ecc) e gli ho dato 777 permessi per frustrazione ...

La mia ipotesi migliore è che qualcosa non va nella configurazione, ma non riesco a capirlo ...

AGGIORNAMENTO Quindi l'ho spostato /var/www/e utilizzato una configurazione molto più semplice:

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

}

Anche se chiamo localhost/console/frontend/www/index.phpottengo un 500 PHP che significa che sta servendo lì. Semplicemente non sta servendo fuori console.ordercloud ...

Il messaggio di errore "script primario sconosciuto" è quasi sempre correlato a un'errata impostazione SCRIPT_FILENAMEnella fastcgi_paramdirettiva nginx (o autorizzazioni errate, vedere altre risposte).

Stai utilizzando un ifnella configurazione che hai pubblicato per primo. Bene, ormai dovrebbe essere ben noto che se è malvagio e spesso produce problemi.

Impostare la rootdirettiva all'interno di un blocco di posizione è una cattiva pratica, ovviamente funziona.

Puoi provare qualcosa di simile al seguente:

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

Si noti che la configurazione sopra non è testata. È necessario eseguire nginx -tprima di applicarlo per verificare la presenza di problemi che nginx è in grado di rilevare immediatamente.

Non è sempre che il SCRIPT_FILENAMEè sbagliato.
Potrebbe anche essere PHP in esecuzione come utente / gruppo errato .

Questo esempio è specifico per Mac OS X , che nella mia esperienza è il più problematico da installare (Debian è facile al confronto) - Ho appena aggiornato da PHP 5.6 a 7.0, usando homebrew e gli eccellenti pacchetti josegonzalez.

Il problema era che è stata creata una nuova copia dei file di configurazione.

Il file di configurazione principale è /usr/local/etc/php/7.0/php-fpm.conf, ma nota la sezione Definizioni pool alla fine in cui include un'intera sottodirectory.

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

In php-fpm.dc'è un www.conffile. Di default questo ha:

user = _www
group = _www

Su OS X, potrebbe essere necessario modificarlo in:

user = [your username]
group = staff

(dovresti trovare che corrisponde a uno ls -lhdei tuoi root_documento)

Sfortunatamente senza questa modifica, lo vedrai comunque nel log degli errori di Nginx anche se sta cercando il file nella posizione corretta .

"Primary script unknown" while reading response header from upstream

Verifica ciò che è attualmente in esecuzione come:

ps aux | grep 'php-fpm'

o più pulito:

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

Come verificare se il nome file dello script è corretto:

(rubato da igorsantos07 nell'altra risposta)

Aggiungi al httpblocco di main /usr/local/etc/nginx/nginx.conf:

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

(dove il primo bit deve essere quello che stai attualmente usando, quindi puoi vedere se è giusto.)

E per utilizzare il registro che hai appena definito, nel serverblocco del tuo sito :

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

Se è corretto, la richiesta di example.com/phpinfo.php produrrà qualcosa del genere:

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

Puoi semplificare la tua configurazione esistente?

Stai usando un location ~ \.php {blocco che hai copiato / incollato da qualche parte su Internet? La maggior parte dei pacchetti ti consente di farlo in modo più rapido e pulito. ad esempio su OS X ora hai solo bisogno di questo:

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

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

Ci sono cose come fastcgi_split_path_info, try_files e fastcgi_index (il default è index.php) /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Ciò a sua volta include /usr/local/etc/nginx/fastcgi.confquale è un elenco di fastcgi_paramimpostazioni, incluso il cruciale SCRIPT_FILENAME.

Non duplicare mai rootnel blocco posizione PHP.

Ok, quindi 3 cose che ho trovato dopo una giornata di lotte

1. Per qualche ragione avevo già qualcosa in esecuzione sulla porta 9000, quindi sono passato a 9001
2. Il mio sito predefinito stava intercettando il mio nuovo, ancora una volta non capisco perché, dal momento che non avrebbe dovuto, ma l'ho appena scollegato
3. Nginx non esegue automaticamente il collegamento sym per i siti disponibili per quelli abilitati al sito.

Spero che questo salvi qualcuno nei guai!

Ha avuto lo stesso problema con un nginx più recente (v1.8). Le versioni più recenti consigliano di utilizzare snippets/fastcgi-php.conf;anziché fastcgi.conf. Quindi, se copi / incolli include fastcgi.confda un tutorial, potresti finire con l' Primary script unknownerrore nel registro.

"Script primario sconosciuto" è causato dal contesto di sicurezza SELinux.

il cliente ottiene la risposta

File non trovato.

nginx error.log presenta il seguente messaggio di errore

* 19 FastCGI ha inviato stderr: "Script primario sconosciuto" durante la lettura dell'intestazione della risposta dall'upstream

quindi basta cambiare il tipo di contesto di sicurezza della cartella principale Web in httpd_sys_content_t

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

ci sono 3 utenti per la configurazione di 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

user-1 e user-2 non sono necessari per essere uguali.

per il socket unix, l'utente-1 deve essere uguale all'utente-3, poiché nginx fastcgi_pass deve disporre dell'autorizzazione di lettura / scrittura sul socket unix.

altrimenti nginx otterrà 502 Bad Gateway e nginx error.log presenta il seguente messaggio di errore

* 36 connect () su unix: /var/run/php-fpm/fpm-www.sock fallito (13: autorizzazione negata) durante la connessione a monte

e l'utente / gruppo della cartella radice web (/ var / www / show) non è necessario essere uguale a nessuno di questi 3 utenti.

Ho avuto anche questo problema, e l'ho risolto scambiando le righe include fastcgi_paramse fastcgi_param SCRIPT_FILENAME ....

Infatti nginx imposta l'ultimo valore di ciascun parametro FastCGI, quindi è necessario inserire il valore dopo il valore predefinito incluso in fastcgi_params.

Ho risolto questo problema chiudendo SELINUX nel sistema CentOS7.3

passaggi:

• exec setenforce 0
• È inoltre necessario modificare il file di configurazione

vim /etc/selinux/config set SELINUX to disabled

Ho trovato la tua domanda cercando lo stesso messaggio di errore ma usando apache + php-fpm (no nginx). Per me, il problema era una barra nel posto sbagliato: molti suggerimenti di installazione includono una riga del modulo:

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

Posizionando l'ultima barra dopo il numero di porta in questo modo:

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

il problema è scomparso per me. Forse puoi fare qualcosa di simile

Ho incontrato la stessa domanda, ma Altro metodo non mi ha aiutato a risolvere la domanda!

Lo risolvo, trovo che la chiave sia: diritto utente Linux porta alla domanda: FastCGI ha inviato stderr: "Script primario sconosciuto"

Perché l'utente predefinito PHP-FPM: group è apache: apache, ma la tua dir del codice è someBody: someBody. Quindi dovresti cambiare l'Utente giusto!

Scrivo un blog per risolvere questa domanda, puoi vedere questo blog:

[Nginx FastCGI ha inviato stderr: "Script primario sconosciuto"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

Ho clonato un sito remoto e il wp-config.php già esistente aveva le informazioni sul database del server remoto.

Ho risolto questo problema impostando la mia configurazione wordpress locale, con le informazioni del mio database locale.

Ho fatto tutto dall'alto, ho perso 2 ore a sbattere la testa e il problema persisteva. Alla fine ho fatto:

sudo service php7.0-fpm restart

E viola ha funzionato!

A proposito, stavo creando un nuovo progetto symfony 3.4 con nginx conf dal link: https://symfony.com/doc/3.4/setup/web_server_configuration.html

Quella era la mia quinta volta di iniziare un nuovo progetto symfony e non potevo credere che questo "Script primario sconosciuto" stesse accadendo.

Controlla le autorizzazioni per il tuo file calzino php-fpm, in qualche modo non era accessibile:

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

quindi prova a riavviare nginx.

Sono stato intrappolato da questo strano messaggio per molto tempo. Non sono sicuro della causa perché tutto ha funzionato per un po 'poi all'improvviso ha smesso di funzionare.

Stavo accorciando gli URL wiki come prescritto da MediaWiki, con Bitnami / Nginx su Lightsail.

Ho cercato e letto molti post, questo sembra riassumere tutti gli scenari possibili e li ho provati tutti:

• nginx va bene, la cartella principale php funziona, la sottocartella no
• errore generato come 404 + una stringa nuda "File non trovato", non da nginx
• aggiungi rootal server, non ha funzionato
• controlla i permessi di cartelle e php-fpm / nginx, nessun problema root e sottocartelle sono uguali
• controllare il manuale di php-fpm per l'interpretazione del codice di errore, impossibile trovarne uno
• attiva il registro di accesso php-fpm, trova l'URI della richiesta corretto, ma viene restituito 404
• prova ad attivare la modalità dettagliata / debug per php-fpm, non ha funzionato, il file di registro errori presunto è sempre vuoto

Così ho dovuto provare l'ultima risorsa, poiché cartella principale php funzionava e sottocartelle non fosse, l'unica differenza di rilievo tra loro diversa rootè la cartella radice utilizzato $request_filenamee della sottocartella luoghi utilizzati $document_roote $fastcgi_script_name, così ho cambiato le impostazioni di posizione sottocartella per abbinare quelli cartella principale.

Poi ha funzionato ... Non sono ancora sicuro del perché abbia funzionato. Perché quando controllo il registro di accesso php-fpm vedo lo stesso URI, uno era 404 e l'altro era 200.

L'unica differenza era nella configurazione. Dato che producono lo stesso output, non so perché il risultato sia risultato diverso.

Comunque ho deciso di pubblicare qui i miei 2 centesimi, spero che questo mi aiuti.

PS: Spero davvero che PHP fornisca migliori messaggi di errore e modalità dettagliata, perché questo è davvero frustrante non essere in grado di isolare il problema e non c'è modo di vedere l'output dettagliato e le informazioni di debug.

Prova ad aggiungere la direttiva root nella tua posizione php.

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