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

81

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

We0
źródło
Inna możliwa przyczyna: jeśli używasz php-fpm, upewnij się, że użytkownik ustawiony w /etc/php-fpm.d/www.conf ma uprawnienia do skryptu, który próbuje uruchomić. Myślę, że domyślnie jest to apache.
Dave
Inna możliwa przyczyna, dla której Twój SElinux jest włączony, sprawdź konfigurację SElinux i wyłącz ją.
CK.Nguyen
Właśnie zmieniłem konfigurację hosta z FCGId (uruchom jako właściciel serwera wirtualnego) na FPM (uruchom jako właściciel serwera wirtualnego). Oprócz instalacji PhP 7.2-fpm, cli i więcej ...
PauloBoaventura

Odpowiedzi:

92

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

Fleshgrinder
źródło
1
To dla mnie rozwiązało; Nie wiedziałem, że musisz przedrostek $ katalog_główny dokumentu, założyłem, że zrobiło to automatycznie, w oparciu o root.
b01
3
Gdzie można dowiedzieć się więcej o złej praktyce ustawiania rootlokalizacji w obrębie?
Dan Dascalescu,
15
Dla tych, którzy nie rozumieją dokładnie, jak zmienna może być źle: Nginx dodać do głównej httpczęści, co następuje: log_format scripts '$document_root$fastcgi_script_name > $request';(lub cokolwiek masz karmienia SCRIPT_FILENAME), a do Twojego server: access_log /var/log/nginx/scripts.log scripts. Przeładuj i spójrz na swój nowy dziennik skryptów;)
igorsantos07
2
Tak,
jasne
3
Co to jest yii_bootstrap?
Uwielbiam
43

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.

William Turrell
źródło
2
bardzo dobrze! to było dla mnie! Zdrowie przyjacielu!
rollsappletree
Dzięki. Dla mnie uruchomione przeze mnie kontenery dokujące fpm / nginx miały problemy z dostępem do tych folderów.
Tek
@ Odpowiedź Fleshgrindera jest nieprawidłowa, a twoja ma rację! W moim przypadku chodziło tylko o poprawienie własności /etc/php/7.0/php-fpm.d/www.confpliku. Na zdrowie, kolego. :) O wiele więcej osób może zacząć widzieć ten problem, ponieważ popularność rośnie.
user392778
nie mogłem znaleźć niczego w środku /usr/local/etc/nginx/snippets/fastcgi-php.confna moim komputerze .. ale znalazłem/usr/local/etc/nginx/fastcgi.conf
abbood
Niezłe!!
Walczyłem
7

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!

We0
źródło
cześć @ we0, mam taki sam problem z konfiguracją. Mam również inną aplikację na porcie 3001, więc muszę hostować moją aplikację php na porcie 3002. Mój oryginalny post możesz zobaczyć tutaj: stackoverflow.com/questions/33229867/... i stackoverflow.com/questions/33409539/... a inny jest stackoverflow.com/questions/33519989/... . Masz jakiś pomysł?
Manish Sapkal
3
Automatyczne udostępnianie dowiązań symbolicznych z witryn do witryn z włączonymi witrynami byłoby, no cóż, niepożądane. Od Ciebie zależy, czy utworzysz te dowiązania symboliczne, abyś mógł kontrolować, które witryny są „włączone”, a które „wyłączone” na twoim serwerze.
Erathiel,
6

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.

Dan Dascalescu
źródło
4

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

PLA
źródło
2

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.

Seb35
źródło
1

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

Kent
źródło
0

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

chrześcijanin
źródło
0

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

Miłość
źródło
0

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.

Shean Hoxie
źródło
0

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

ermacmkx
źródło
0

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.

spetsnaz
źródło
0

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.

wprowadź opis zdjęcia tutaj

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.

Dai
źródło
-1

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

location ~ \.php {
      root /home/willem/git/console/www;
      ...
}
lg.
źródło
1
rootDyrektywa powinna być ustawiona w przeliczeniu na serverzasadach i nie powinny być wykorzystywane w jakichkolwiek locationbloków (chyba, że jesteś pro i chcą obejść pewne bardzo szczególne błędy nginx w konfiguracji).
Fleshgrinder
1
@Fleshgrinder jeden root na serwer nie jest najlepszą praktyką.
Garet Claborn,
Tak,
jasne
@Fleshgrinder Nie tak mówi sekcja, którą połączyłeś. Przykład dobrej praktyki w tej sekcji pokazuje rootdyrektywę wewnątrz locationbloku.
ishigoya
@ishigoya, proszę ponownie odwiedzić link, wiele rootdyrektyw w wielu locationblokach jest wyraźnie pod nagłówkiem ZŁE.
Fleshgrinder