Nginx 1 FastCGI được gửi trong stderr: Kịch bản chính chưa biết


81

Lần đầu tiên tôi sử dụng Nginx, nhưng tôi không quen với Apache và Linux. Tôi đang sử dụng một dự án hiện có và khi tôi đang cố gắng xem index.php thì tôi không tìm thấy Tệp 404.

Đây là mục 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"

Và đây là tập tin có sẵn trên trang web:

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

My / home / willem / git / console được sở hữu bởi www-data: www-data (người dùng web của tôi chạy php, v.v.) và tôi đã cấp cho nó 777 quyền vì thất vọng ...

Dự đoán tốt nhất của tôi là có gì đó không đúng với cấu hình, nhưng tôi không thể tìm ra ...

CẬP NHẬT Vì vậy, tôi đã chuyển nó sang /var/www/và sử dụng một cấu hình cơ bản hơn nhiều:

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

}

Ngoài ra nếu tôi gọi localhost/console/frontend/www/index.phptôi nhận được 500 PHP có nghĩa là nó đang phục vụ ở đó. Nó chỉ không phục vụ ra khỏi console.ordercloud ...


Một nguyên nhân có thể khác: Nếu bạn đang sử dụng php-fpm, hãy đảm bảo rằng người dùng được đặt trong /etc/php-fpm.d/www.conf có quyền cho tập lệnh mà nó đang cố chạy. Tôi nghĩ rằng nó mặc định để apache.
Dave

Một nguyên nhân có thể khác khiến SElinux của bạn được bật, kiểm tra cấu hình SElinux và vô hiệu hóa nó.
CK.Nguyen

Tôi vừa chuyển Cấu hình máy chủ của mình từ FCGId (chạy với tư cách là chủ sở hữu máy chủ ảo) sang FPM (chạy với tư cách là chủ sở hữu máy chủ ảo). Ngoài việc cài đặt PhP 7.2-fpm, cli và hơn thế nữa ...
PauloBoaventura

Câu trả lời:


92

Thông báo lỗi Tập lệnh chính không rõ ràng của tập tin, hầu như luôn luôn liên quan đến một tập hợp sai SCRIPT_FILENAMEtrong lệnh nginx fastcgi_param(hoặc quyền không chính xác, xem các câu trả lời khác).

Bạn đang sử dụng một iftrong cấu hình bạn đã đăng đầu tiên. Bây giờ nó nên được biết rằng nếu là xấu xa và thường tạo ra vấn đề.

Đặt lệnh roottrong một khối vị trí là thực tế xấu, tất nhiên nó hoạt động.

Bạn có thể thử một cái gì đó như sau:

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

Xin lưu ý rằng cấu hình trên chưa được kiểm tra. Bạn nên thực thi nginx -ttrước khi áp dụng nó để kiểm tra các vấn đề mà nginx có thể phát hiện ngay lập tức.


1
Điều này giải quyết nó cho tôi; Tôi không biết rằng bạn phải đặt tiền tố $ document_root, tôi cho rằng nó đã tự động làm điều đó, dựa trên root.
b01

3
Nơi nào người ta có thể tìm hiểu thêm về thực tiễn xấu của việc đặt rootvị trí bên trong?
Dan Dascalescu

15
Đối với những người không hiểu chính xác biến số có thể sai như thế nào: hãy thêm vào httpphần Nginx chính như sau: log_format scripts '$document_root$fastcgi_script_name > $request';(hoặc bất cứ điều gì bạn đang cho SCRIPT_FILENAME) và vào server: access_log /var/log/nginx/scripts.log scripts. Tải lại và xem nhật ký tập lệnh mới của bạn;)
igorsantos07


3
Yii_bootstrap là gì?
Yêu

43

Không phải lúc nào điều đó SCRIPT_FILENAMEcũng sai.
Nó cũng có thể là PHP đang chạy như người dùng / nhóm sai .

Ví dụ này dành riêng cho Mac OS X , theo kinh nghiệm của tôi là khó cài đặt nhất (Debian rất dễ so sánh) - Tôi vừa nâng cấp từ PHP 5.6 lên 7.0, sử dụng homebrew và các gói josegonzalez tuyệt vời.

Vấn đề là một bản sao mới của các tập tin cấu hình đã được tạo.

Tệp cấu hình chính là /usr/local/etc/php/7.0/php-fpm.conf, nhưng lưu ý phần Định nghĩa nhóm ở cuối nơi chứa toàn bộ thư mục con.

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

Trong php-fpm.dđó có một www.conftập tin. Theo mặc định, điều này có:

user = _www
group = _www

Trên OS X, bạn có thể cần thay đổi điều này thành:

user = [your username]
group = staff

(bạn sẽ tìm thấy cái này khớp với ls -lhtài liệu của bạn_root)

Thật không may, không có thay đổi này, bạn vẫn sẽ thấy điều này trong nhật ký lỗi Nginx của mình ngay cả khi nó đang tìm tệp ở đúng vị trí .

"Primary script unknown" while reading response header from upstream

Xác minh những gì nó hiện đang chạy như:

ps aux | grep 'php-fpm'

hoặc sạch sẽ hơn:

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

Cách xác minh xem tên tệp script có đúng không:

(bị đánh cắp từ igorsantos07 trong câu trả lời khác)

Thêm vào httpkhối chính /usr/local/etc/nginx/nginx.conf:

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

(trong đó bit đầu tiên cần là bất cứ thứ gì bạn đang sử dụng, vì vậy bạn có thể xem liệu nó có đúng không.)

Và để sử dụng nhật ký bạn vừa xác định, trong serverkhối trang web của bạn :

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

Nếu đúng, yêu cầu example.com/phpinfo.php sẽ tạo ra một cái gì đó như thế này:

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

Bạn có thể đơn giản hóa cấu hình hiện tại của bạn?

Bạn có đang sử dụng một location ~ \.php {khối bạn đã sao chép / dán từ một nơi nào đó trên internet không? Hầu hết các gói cho phép bạn làm điều đó nhanh chóng và sạch sẽ hơn. ví dụ trên OS X bây giờ bạn chỉ cần điều này:

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

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

Những thứ như fastcgi_split_path_info, try_files và fastcgi_index (mặc định là index.php) được đưa vào /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Đến lượt nó bao gồm /usr/local/etc/nginx/fastcgi.confmột danh sách các fastcgi_paramcài đặt, bao gồm cả SCRIPT_FILENAME quan trọng.

Đừng bao giờ trùng lặp roottrong khối vị trí PHP.


2
rất đẹp! đó là cho tôi Cổ vũ người bạn đời!
rollappletree

Cảm ơn. Đối với tôi, các container docker fpm / nginx mà tôi đang chạy có vấn đề về quyền truy cập các thư mục này.
Tek

Câu trả lời của @ F Meatgrinder là sai và câu trả lời của bạn là đúng! Trong trường hợp của tôi, đó thực sự chỉ là vấn đề sửa quyền sở hữu trong /etc/php/7.0/php-fpm.d/www.conftập tin. Chúc mừng bạn, nụ. :) Nhiều người có thể bắt đầu thấy vấn đề này cũng như sự phổ biến mơ hồ tiếp tục tăng lên.
dùng392778

không thể tìm thấy bất cứ thứ gì bên trong máy /usr/local/etc/nginx/snippets/fastcgi-php.confmac của tôi .. nhưng tôi đã tìm thấy/usr/local/etc/nginx/fastcgi.conf
abbood

Đẹp đấy !! Đã vật lộn trong nhiều giờ
fonini

7

Ok, vậy là 3 điều tôi tìm thấy sau một ngày vật lộn

  1. Vì một số lý do, tôi đã có một cái gì đó chạy trên cổng 9000 nên tôi đổi thành 9001
  2. Trang web mặc định của tôi đã chặn trang mới của tôi, một lần nữa tôi không hiểu tại sao vì nó không nên, nhưng tôi chỉ hủy liên kết nó
  3. Nginx không tự động thực hiện liên kết sym cho các trang có sẵn để kích hoạt trang.

Hy vọng điều này sẽ cứu ai đó một số rắc rối!


xin chào @ we0, tôi gặp phải vấn đề tương tự với thiết lập của mình. Tôi cũng đã chạy ứng dụng của tôi khác trên cổng 3001, vì vậy tôi có để lưu trữ ứng dụng php của tôi trên cổng 3002. Bạn có thể xem bài gốc của tôi ở đây: stackoverflow.com/questions/33229867/...stackoverflow.com/questions/33409539/... và một cái khác là stackoverflow.com/questions/33519989/ . Bạn còn ý kiến ​​nào không?
Manish Sapkal

3
Tự động tạo liên kết tượng trưng từ các trang web có sẵn đến các trang web được kích hoạt sẽ là điều không mong muốn. Tùy thuộc vào bạn để tạo các liên kết tượng trưng đó để bạn có thể kiểm soát các trang web nào được 'bật' và trang web nào 'tắt' trên máy chủ của bạn.
Erathiel

6

Có cùng một vấn đề với nginx mới hơn (v1.8). Các phiên bản mới hơn khuyên bạn nên sử dụng snippets/fastcgi-php.conf;thay vì fastcgi.conf. Vì vậy, nếu bạn sao chép / dán include fastcgi.conftừ một hướng dẫn, bạn có thể sẽ Primary script unknowngặp lỗi trong nhật ký.


4

"Không biết tập lệnh chính" là do bối cảnh bảo mật của Selinux.

khách hàng nhận được phản hồi

Không tìm thấy tập tin.

nginx error.log có thông báo lỗi sau

* 19 FastCGI được gửi trong stderr: "Không biết tập lệnh chính" trong khi đọc tiêu đề phản hồi từ thượng nguồn

vì vậy chỉ cần thay đổi loại ngữ cảnh bảo mật của thư mục gốc web thành httpd_sys_content_t

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




Có 3 người dùng cho cấu hình 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

người dùng-1 và người dùng-2 không cần thiết phải giống nhau.

đối với ổ cắm unix, người dùng-1 cần giống với người dùng-3, vì nginx fastcgi_pass phải có quyền đọc / ghi trên ổ cắm unix.

nếu không nginx sẽ nhận được 502 Bad Gateway và nginx error.log có thông báo lỗi sau

* 36 kết nối () với unix: /var/run/php-fpm/fpm-www.sock không thành công (13: Quyền bị từ chối) trong khi kết nối với thượng nguồn

và người dùng / nhóm thư mục gốc web (/ var / www / show) không cần thiết phải giống với bất kỳ ai trong số 3 người dùng này.


2

Tôi cũng có vấn đề này, và tôi đã giải quyết nó bằng cách trao đổi các dòng include fastcgi_paramsfastcgi_param SCRIPT_FILENAME ....

Thật vậy, nginx đặt giá trị cuối cùng của từng tham số FastCGI, vì vậy bạn phải đặt giá trị của mình sau giá trị mặc định được bao gồm trong fastcgi_params.


1

Tôi đã giải quyết vấn đề này bằng cách đóng SELINUX trong hệ thống CentOS7.3

các bước:

  • thực hiện setenforce 0
  • Bạn cũng cần sửa đổi tập tin cấu hình

vim /etc/selinux/config set SELINUX to disabled


0

Tôi thấy câu hỏi của bạn đang tìm kiếm thông báo lỗi tương tự nhưng sử dụng apache + php-fpm (không có nginx). Đối với tôi, vấn đề là một dấu gạch chéo sai vị trí: nhiều đề xuất thiết lập bao gồm một dòng của biểu mẫu:

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

Bằng cách đặt dấu gạch chéo cuối cùng sau số cổng như vậy:

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

vấn đề đã biến mất đối với tôi. Có lẽ bạn có thể làm một cái gì đó tương tự


0

Tôi gặp câu hỏi tương tự, nhưng phương pháp khác không giúp tôi giải quyết câu hỏi!

Tôi giải quyết nó, tôi thấy điểm mấu chốt là: Người dùng Linux phải dẫn đến câu hỏi: FastCGI được gửi trong stderr: "Không biết tập lệnh chính"

Bởi vì người dùng mặc định PHP-FPM: nhóm là apache: apache, nhưng mã dir của bạn là someBody: someBody. Vì vậy, bạn nên thay đổi người dùng ngay!

Tôi viết một blog để giải quyết câu hỏi này, Bạn có thể xem blog này:

[Nginx FastCGI được gửi trong stderr: "Không biết tập lệnh chính"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html


0

Tôi đã nhân bản một trang web từ xa và wp-config.php đã có sẵn thông tin cơ sở dữ liệu máy chủ từ xa.

Tôi đã giải quyết vấn đề này bằng cách thiết lập cấu hình wordpress cục bộ, với thông tin cơ sở dữ liệu cục bộ của tôi.


0

Tôi đã làm mọi thứ từ trên cao, mất 2 tiếng đập đầu và vấn đề vẫn còn tồn tại. Cuối cùng tôi đã làm:

sudo service php7.0-fpm restart

Và viola nó đã làm việc!

Btw, tôi đã thiết lập dự án symfony 3.4 mới với nginx conf từ liên kết: https://symfony.com/doc/3.4/setup/web_server_configuration.html

Đó là lần thứ năm tôi bắt đầu dự án symfony mới và tôi không thể tin rằng "kịch bản chính chưa biết" này đang xảy ra.


0

Kiểm tra quyền cho tệp sock php-fpm của bạn, bằng cách nào đó nó không thể truy cập được:

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

sau đó thử khởi động lại nginx.


0

Tôi đã bị mắc kẹt bởi tin nhắn kỳ lạ này trong một thời gian rất dài. Tôi không chắc chắn về nguyên nhân bởi vì mọi thứ hoạt động được một lúc thì đột nhiên nó ngừng hoạt động.

Tôi đã rút ngắn các URL wiki theo quy định của MediaWiki, với Bitnami / Nginx trên Lightsail.

Tìm kiếm và đọc nhiều bài viết, bài viết này dường như tóm tắt tất cả các tình huống có thể xảy ra và tôi đã thử tất cả:

  • nginx vẫn ổn, thư mục gốc php đang hoạt động, thư mục con không
  • lỗi được ném là 404 + một chuỗi trần "Không tìm thấy tệp", không phải bởi nginx
  • thêm rootvào máy chủ, không hoạt động
  • kiểm tra quyền của thư mục và php-fpm / nginx, không có vấn đề gốc và thư mục con nào giống nhau
  • kiểm tra hướng dẫn sử dụng php-fpm để giải thích mã lỗi, không thể tìm thấy
  • bật nhật ký truy cập php-fpm, thấy URI yêu cầu đã đúng, nhưng 404 được trả về
  • hãy thử bật chế độ verbose / debug cho php-fpm, không hoạt động, tệp nhật ký lỗi được cho là luôn trống

Vì vậy, tôi đã phải thử phương án cuối cùng, vì thư mục gốc php đã hoạt động và các thư mục con thì không, sự khác biệt lớn duy nhất giữa chúng rootlà thư mục gốc được sử dụng $request_filenamevà các vị trí thư mục con được sử dụng $document_root$fastcgi_script_namevì vậy tôi đã thay đổi cài đặt vị trí thư mục con để khớp với thư mục gốc.

Sau đó, nó hoạt động ... Tôi vẫn không chắc tại sao nó hoạt động. Bởi vì khi tôi kiểm tra nhật ký truy cập php-fpm tôi thấy cùng một URI, một cái là 404 và cái kia là 200.

nhập mô tả hình ảnh ở đây

Sự khác biệt duy nhất là trong cấu hình. Vì chúng tạo ra cùng một đầu ra, tôi không biết tại sao kết quả lại khác nhau.

Dù sao tôi đã quyết định đăng 2 xu của tôi ở đây, hy vọng điều này sẽ giúp.

PS: Tôi thực sự hy vọng PHP cung cấp các thông báo lỗi và chế độ dài dòng tốt hơn, bởi vì điều này thực sự gây khó chịu khi không thể cô lập vấn đề và không có cách nào để xem thông tin gỡ lỗi và thông tin gỡ lỗi.


-1

Cố gắng thêm chỉ thị gốc trong vị trí php của bạn.

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

1
Lệnh rootnày phải được đặt theo từng servercơ sở và không nên được sử dụng trong bất kỳ locationkhối nào (trừ khi bạn là dân chuyên nghiệp và muốn tránh một số lỗi nginx rất đặc biệt trong cấu hình của bạn).
F Meatgrinder

1
@F Meatgrinder một root cho mỗi máy chủ không phải là cách tốt nhất.
Garet Claborn


@F Meatgrinder Đó không phải là những gì phần bạn liên kết nói. Ví dụ về thực hành tốt trong phần đó cho thấy một rootchỉ thị bên trong một locationkhối.
ishigoya

@ishigoya vui lòng truy cập lại liên kết, nhiều rootchỉ thị bên trong nhiều locationkhối rõ ràng nằm dưới tiêu đề BAD.
Xác thịt
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.