Nginx 1 FastCGI wysłany w stderr: „Podstawowy skrypt nieznany”

Pierwszy raz korzystam z Nginx, ale jestem bardziej niż zaznajomiony z Apache i Linuksem. Korzystam z istniejącego projektu i kiedy próbuję zobaczyć plik index.php, nie mogę znaleźć pliku 404.

Oto wpis 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"

A oto plik dostępny na stronach:

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

Mój / home / willem / git / console jest własnością www-data: www-data (mój użytkownik korzystający z php itp.) I dałem mu 777 uprawnień z frustracji ...

Domyślam się, że coś jest nie tak z konfiguracją, ale nie mogę tego rozgryźć ...

AKTUALIZACJA Więc przeniosłem go /var/www/i użyłem znacznie bardziej podstawowej konfiguracji:

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

}

Również jeśli zadzwonię localhost/console/frontend/www/index.php, dostanę 500 PHP, co oznacza, że ​​tam służy. To po prostu nie służy off.cloudcloud ...

Komunikat o błędzie „podstawowy skrypt nieznany” jest prawie zawsze związany z niepoprawnie ustawionym SCRIPT_FILENAMEw fastcgi_paramdyrektywie nginx (lub niepoprawnymi uprawnieniami, zobacz inne odpowiedzi).

Używasz ifw konfiguracji, którą opublikowałeś jako pierwszy. Cóż, do tej pory powinno być dobrze znane, że jeśli jest zły i często powoduje problemy.

Ustawienie rootdyrektywy w bloku lokalizacji to zła praktyka, oczywiście, że działa.

Możesz spróbować czegoś takiego:

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

Pamiętaj, że powyższa konfiguracja nie została przetestowana. Powinieneś wykonać go nginx -tprzed zastosowaniem, aby sprawdzić problemy, które nginx może natychmiast wykryć.

Nie zawszeSCRIPT_FILENAME jest tak, że coś jest nie tak.
Być może PHP działa jako niewłaściwy użytkownik / grupa .

Ten przykład jest specyficzny dla Mac OS X , który z mojego doświadczenia jest najbardziej kłopotliwy w konfiguracji (Debian jest łatwy do porównania) - właśnie zaktualizowałem PHP z wersji 5.6 do 7.0, używając homebrew i doskonałych pakietów josegonzalez.

Problem polegał na tym, że utworzono nową kopię plików konfiguracyjnych.

Głównym plikiem konfiguracyjnym jest /usr/local/etc/php/7.0/php-fpm.conf, ale zwróć uwagę na sekcję Definicje puli na końcu, która zawiera cały podkatalog.

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

W php-fpm.distnieje www.confplik. Domyślnie ma to:

user = _www
group = _www

W systemie OS X może być konieczna zmiana tego ustawienia na:

user = [your username]
group = staff

(powinieneś znaleźć to pasujące do ls -lhtwojego root_dokumentu)

Niestety bez tej zmiany nadal będzie to widoczne w dzienniku błędów Nginx, nawet jeśli szuka pliku we właściwym miejscu .

"Primary script unknown" while reading response header from upstream

Sprawdź, co aktualnie działa jako:

ps aux | grep 'php-fpm'

lub bardziej czysto:

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

Jak sprawdzić, czy nazwa pliku skryptu jest poprawna:

(skradziony z igorsantos07 w innej odpowiedzi)

Dodaj do httpbloku głównego /usr/local/etc/nginx/nginx.conf:

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

(gdzie pierwszym bitem musi być to, czego aktualnie używasz, abyś mógł sprawdzić, czy to prawda).

Aby użyć dziennika, który właśnie zdefiniowałeś, w serverbloku witryny :

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

Jeśli jest to poprawne, żądanie przykład.com/phpinfo.php spowoduje wygenerowanie czegoś takiego:

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

Czy możesz uprościć istniejącą konfigurację?

Czy używasz location ~ \.php {bloku, który skopiowałeś / wkleiłeś z Internetu? Większość pakietów pozwala ci to zrobić szybciej i czysto. np. w OS X potrzebujesz teraz tego:

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

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

Dostępne są rzeczy takie jak fastcgi_split_path_info, try_files i fastcgi_index (domyślnie index.php) /usr/local/etc/nginx/snippets/fastcgi-php.conf.

To z kolei obejmuje /usr/local/etc/nginx/fastcgi.conflistę fastcgi_paramustawień, w tym kluczową SCRIPT_FILENAME.

Nigdy nie duplikuj rootw bloku lokalizacji PHP.

Ok, więc 3 rzeczy znalazłem po całym dniu walki

1. Z jakiegoś powodu miałem już coś uruchomionego na porcie 9000, więc zmieniłem na 9001
2. Moja domyślna witryna przechwytywała moją nową, jeszcze raz nie rozumiem dlaczego, ponieważ nie powinna, ale po prostu ją odłączyłem
3. Nginx nie wykonuje automatycznie linku sym dla stron dostępnych dla stron obsługujących witrynę.

Mam nadzieję, że zaoszczędzi to komuś kłopotów!

Miał ten sam problem z nowszym nginx (v1.8). Nowsze wersje zalecają używanie snippets/fastcgi-php.conf;zamiast fastcgi.conf. Więc jeśli skopiujesz / wkleisz include fastcgi.confz samouczka, możesz skończyć z Primary script unknownbłędem w dzienniku.

„Podstawowy skrypt nieznany” jest spowodowany kontekstem bezpieczeństwa SELinux.

klient otrzymuje odpowiedź

Nie znaleziono pliku.

Nginx error.log ma następujący komunikat o błędzie

* 19 FastCGI wysłany w stderr: „Główny skrypt nieznany” podczas odczytywania nagłówka odpowiedzi z poprzedzającego

więc po prostu zmień typ kontekstu bezpieczeństwa internetowego folderu głównego na httpd_sys_content_t

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

dla konfiguracji nginx / php-fpm jest 3 użytkowników

/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

użytkownik-1 i użytkownik-2 nie muszą być tacy sami.

w przypadku gniazda unix użytkownik-1 musi być taki sam jak użytkownik-3, ponieważ nginx fastcgi_pass musi mieć uprawnienia do odczytu / zapisu w gnieździe unix.

w przeciwnym razie nginx otrzyma 502 Bad Gateway , a nginx error.log wyświetli następujący komunikat o błędzie

* 36 connect () do unix: /var/run/php-fpm/fpm-www.sock nie powiodło się (13: Odmowa dostępu) podczas łączenia się z nadrzędnym

a użytkownik / grupa folderu głównego (/ var / www / show) nie musi być taki sam jak którykolwiek z tych 3 użytkowników.

Miałem również ten problem i rozwiązałem go, wymieniając linie include fastcgi_paramsi fastcgi_param SCRIPT_FILENAME ....

Rzeczywiście nginx ustawia ostatnią wartość każdego parametru FastCGI, więc musisz umieścić swoją wartość po wartości domyślnej zawartej w fastcgi_params.

Rozwiązałem ten problem, zamykając SELINUX w systemie CentOS7.3

kroki:

• exec setenforce 0
• Musisz także zmodyfikować plik konfiguracyjny

vim /etc/selinux/config set SELINUX to disabled

Znalazłem twoje pytanie szukające tego samego komunikatu o błędzie, ale używając apache + php-fpm (bez nginx). Dla mnie problemem był ukośnik w niewłaściwym miejscu: wiele sugestii dotyczących konfiguracji zawiera wiersz formularza:

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

Umieszczając ostatni ukośnik po numerze portu w następujący sposób:

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

problem zniknął dla mnie. Może możesz zrobić coś podobnego

Spełniam to samo pytanie, ale inna metoda nie pomogła mi rozwiązać pytania!

Rozwiązuję to, uważam, że kluczem jest: Linux User Right prowadzi do pytania: FastCGI wysłany w stderr: „Podstawowy skrypt nieznany”

Ponieważ domyślnym użytkownikiem PHP-FPM: grupa jest apache: apache, ale katalogiem kodu jest someBody: someBody. Więc powinieneś zmienić prawo użytkownika!

Piszę blog, aby rozwiązać to pytanie. Możesz zobaczyć tego bloga:

[Nginx FastCGI wysłany w stderr: „Główny skrypt nieznany”] [1] „[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

Sklonowałem zdalną witrynę, a już istniejąca wp-config.php zawierała informacje o bazie danych zdalnego serwera.

Rozwiązałem ten problem, konfigurując moją lokalną konfigurację wordpress z informacjami o mojej lokalnej bazie danych.

Zrobiłem wszystko z góry, straciłem 2 godziny waląc głową i problem nadal występował. Wreszcie zrobiłem:

sudo service php7.0-fpm restart

I altówka zadziałała!

Przy okazji, tworzyłem nowy projekt symfony 3.4 z nginx conf z linku: https://symfony.com/doc/3.4/setup/web_server_configuration.html

To był mój piąty raz, kiedy zaczynałem nowy projekt symfony i nie mogłem uwierzyć, że dzieje się ten „scenariusz podstawowy nieznany”.

Sprawdź uprawnienia do pliku skarpety php-fpm, jakoś nie był dostępny:

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

następnie spróbuj zrestartować nginx.

Bardzo dziwna wiadomość mnie uwięziła. Nie jestem pewien co do przyczyny, ponieważ wszystko działało przez chwilę, a potem nagle przestało działać.

Skracałem adresy URL wiki zgodnie z zaleceniami MediaWiki, używając Bitnami / Nginx na Lightsail.

Przeszukałem i przeczytałem wiele postów, ten wydaje się podsumowywać wszystkie możliwe scenariusze, a ja wypróbowałem je wszystkie:

• nginx jest w porządku, folder główny php działa, podfolder nie działa
• błąd wyrzucony jako 404 + czysty ciąg „Nie znaleziono pliku”, nie przez nginx
• dodaj rootdo serwera, nie działało
• sprawdź uprawnienia do folderów i php-fpm / nginx, bez problemu root i podfoldery są takie same
• sprawdź podręcznik php-fpm pod kątem interpretacji kodu błędu, nie można go znaleźć
• włącz dziennik dostępu php-fpm, okazało się, że identyfikator URI żądania jest poprawny, ale zwracany jest kod 404
• spróbuj włączyć tryb pełny / debugowania dla php-fpm, nie działał, domniemany plik dziennika błędów jest zawsze pusty

Więc musiałem spróbować ostateczności, ponieważ folder główny php działa i podfoldery nie było, tylko duża różnica między nimi inny niż rootjest folderów korzeń używany $request_filenamei podfolderów lokalizacje wykorzystywane $document_rooti $fastcgi_script_nametak zmieniłem ustawienia lokalizacji podfolder, aby dopasować te folderze głównym.

Potem zadziałało ... Nadal nie jestem pewien, dlaczego zadziałało. Ponieważ kiedy sprawdzam dziennik dostępu php-fpm, widzę ten sam URI, jeden miał 404, a drugi 200.

Jedyną różnicą była konfiguracja. Ponieważ produkują taką samą wydajność, nie wiem, dlaczego wynik wyszedł inaczej.

W każdym razie postanowiłem tutaj zamieścić 2 centy, mam nadzieję, że to pomoże.

PS: Naprawdę mam nadzieję, że PHP dostarczy lepsze komunikaty o błędach i tryb gadatliwy, ponieważ jest to naprawdę frustrujące, ponieważ nie mogę wyodrębnić problemu i nie ma sposobu, aby zobaczyć pełne dane wyjściowe i informacje debugowania.

Spróbuj dodać dyrektywę root w swojej lokalizacji php.

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