Nginx 1 FastCGI надсилається в stderr: "Невідомий первинний сценарій"

Я вперше використовую Nginx, але я більше, ніж знайомий з Apache та Linux. Я використовую існуючий проект, і коли-небудь я намагаюся побачити index.php, я отримую файл 404 не знайдено.

Ось запис 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"

А ось файл, доступний для сайтів:

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

Мій / home / willem / git / console належить www-data: www-data (мій веб-користувач, що працює php тощо), і я дав йому 777 дозволів із-за розчарування ...

Я найкраще здогадуюсь, що з конфігурацією щось не так, але я не можу це зрозуміти ...

ОНОВЛЕННЯ Отже, я перемістив його до /var/www/і використав набагато більш базовий конфігурацію:

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

}

Крім того, якщо я телефоную, localhost/console/frontend/www/index.phpя отримую 500 PHP, що означає, що він там обслуговується. Він просто не обслуговує console.ordercloud ...

Повідомлення про помилку «первинний невідомий сценарій» майже завжди пов’язане з неправильно встановленою директивою SCRIPT_FILENAMEnginx fastcgi_param(або неправильними дозволами, див. Інші відповіді).

Ви використовуєте ifконфігурацію, яку ви опублікували першою. Ну, на сьогодні слід добре знати, що якщо це зло і часто створює проблеми.

Встановлення rootдирективи в межах локального блоку є поганою практикою, звичайно, це працює.

Ви можете спробувати щось подібне:

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

Зверніть увагу, що наведена вище конфігурація не перевірена. Ви повинні виконати його nginx -tперед тим, як застосувати його, щоб перевірити проблеми, які nginx може виявити відразу.

Це не завжди , що SCRIPT_FILENAMEце неправильно.
Можливо, PHP працює як неправильний користувач / група .

Цей приклад характерний для Mac OS X , який, на мій досвід, є найскладнішим у налаштуванні (Debian є легким для порівняння) - я щойно оновив з PHP 5.6 до 7.0, використовуючи homebrew та чудові пакети josegonzalez.

Проблема полягала в тому, що була створена нова копія конфігураційних файлів.

Основний файл конфігурації є /usr/local/etc/php/7.0/php-fpm.conf, але зверніть увагу на розділ Визначення пулу в кінці, де він містить цілий підкаталог.

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

В php-fpm.dє www.confфайл. За замовчуванням це:

user = _www
group = _www

В OS X вам може знадобитися змінити це на:

user = [your username]
group = staff

(ви повинні знайти це збігається ls -lhз вашим документом_root)

На жаль, без цієї зміни ви все одно побачите це у своєму журналі помилок Nginx, навіть якщо шукаєте файл у потрібному місці .

"Primary script unknown" while reading response header from upstream

Перевірте, як працює зараз:

ps aux | grep 'php-fpm'

або більш чисто:

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

Як перевірити правильність імені файлу сценарію:

(викрадено у igorsantos07 в іншій відповіді)

Додати до httpблоку основного /usr/local/etc/nginx/nginx.conf:

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

(де першим бітом має бути все, що ви зараз використовуєте, щоб ви могли бачити, чи правильно це.)

І використовувати журнал ви тільки що визначили, в вашому сайті serverблоку:

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

Якщо це правильно, запит example.com/phpinfo.php видасть щось подібне:

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

Чи можете ви спростити існуючу конфігурацію?

Ви використовуєте location ~ \.php {блок, який ви скопіювали / вставили звідкись із Інтернету? Більшість пакетів дозволяють зробити це швидше і чисто. наприклад, для OS X зараз вам знадобиться лише це:

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

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

Такі речі, як fastcgi_split_path_info, try_files та fastcgi_index (за замовчуванням до index.php) /usr/local/etc/nginx/snippets/fastcgi-php.conf.

Це, в свою чергу, включає /usr/local/etc/nginx/fastcgi.confсписок fastcgi_paramналаштувань, включаючи вирішальне значення SCRIPT_FILENAME.

Ніколи не дублюйте rootв блоці розташування PHP.

Добре, так що 3 речі я знайшов після дня боротьби

1. Чомусь у мене вже щось працює на порту 9000, тому я змінився на 9001
2. Мій сайт за замовчуванням перехоплював мій новий, я ще раз не знаю, чому так не слід, але я просто від’єднав його
3. Nginx не робить автоматично посилання на сайти, доступні для веб-сайтів.

Сподіваюся, це врятує когось певну неприємність!

Була така ж проблема з новішим nginx (v1.8). Новіші версії рекомендують використовувати snippets/fastcgi-php.conf;замість fastcgi.conf. Отже, якщо ви скопіювали / вставили include fastcgi.confз підручника, ви можете виявити Primary script unknownпомилку в журналі.

"Невідомий первинний сценарій" викликаний контекстом безпеки SELinux.

клієнт отримує відповідь

Файл не знайдено.

nginx error.log має таке повідомлення про помилку

* 19 FastCGI, надісланий у stderr: "Первинний сценарій невідомий" під час зчитування заголовка відповіді з висхідного потоку

тому просто змініть тип контексту безпеки веб-кореневої папки на httpd_sys_content_t

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

є 3 користувачі для nginx / php-fpm config

/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 і user-2 не повинні бути однаковими.

для unix socket, user-1 повинен бути таким же, як user-3, оскільки nginx fastcgi_pass повинен мати дозвіл на читання / запис у unix-сокет.

інакше nginx отримає 502 Bad Gateway , а nginx error.log має таке повідомлення про помилку

* 36 підключення () до unix: /var/run/php-fpm/fpm-www.sock не вдалося (13: дозвіл відхилено) під час підключення до upstream

і користувач / група веб-кореневої папки (/ var / www / show) не обов'язково бути таким, як будь-який із цих 3 користувачів.

У мене було і це питання, і я вирішив його, обмінявшись рядками include fastcgi_paramsта fastcgi_param SCRIPT_FILENAME ....

Дійсно, nginx встановлює останнє значення кожного параметра FastCGI, тому вам потрібно поставити своє значення після значення за замовчуванням, включеного у fastcgi_params.

Я вирішив цю проблему, закривши SELINUX у системі CentOS7.3

кроки:

• виконувати setenforce 0
• Вам також потрібно змінити конфігураційний файл

vim /etc/selinux/config set SELINUX to disabled

Я виявив, що ваше запитання шукає те саме повідомлення про помилку, але використовуючи apache + php-fpm (без nginx). Для мене проблема полягала в нахилі в неправильному місці: багато пропозицій щодо налаштування містять рядок форми:

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

Розмістивши останню косу рису після номера порту так:

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

проблема зникла для мене. Можливо, ви можете зробити щось подібне

Я зустрічаюсь з тим же питанням, але Інший метод не допоміг мені вирішити питання!

Я вирішую це, я вважаю, що ключ: Право користувача Linux призводить до питання: FastCGI, що надсилається в stderr: "Первинний сценарій невідомий"

Оскільки користувач PHP-FPM за замовчуванням користувач: group є apache: apache, Але ваш код dir - деякийBody: someBody. Отже, ви повинні змінити права користувача!

Я пишу щоденник, щоб вирішити це питання. Ви можете бачити цей блог:

[Nginx FastCGI, надісланий у stderr: "Невідомий первинний сценарій"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

Я клонував віддалений сайт, і вже наявна wp-config.php мала інформацію про базу даних віддаленого сервера.

Я вирішив цю проблему, встановивши локальну конфігурацію wordpress із моєю інформацією про локальну базу даних.

Я все робив зверху, втратив 2 години, стукаючи головою, і проблема все ще зберігалася. Нарешті я зробив:

sudo service php7.0-fpm restart

І віола спрацювала!

До речі, я створював новий проект symfony 3.4 з nginx conf за посиланням: https://symfony.com/doc/3.4/setup/web_server_configuration.html

То був мій п'ятий раз, коли я починав новий проект Symfony, і я не міг повірити, що це відбувається "Невідомий первинний сценарій".

Перевірте дозволи на ваш файл шкарпетки php-fpm, якось це було недоступно:

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

потім спробуйте перезапустити nginx.

Я дуже довго опинився в пастці від цього дивного повідомлення. Я не впевнений у цій причині, бо все працював деякий час, а потім раптом перестав працювати.

Я скорочував URL-адреси вікі, як це прописано MediaWiki, за допомогою Bitnami / Nginx на Lightsail.

Шукав і читав багато публікацій, цей, здається, узагальнює всі можливі сценарії, і я спробував їх усі:

• nginx добре, коренева папка php працює, підпапка - ні
• помилка, викинута як 404 + голий рядок "Файл не знайдено", не nginx
• додати rootна сервер, не працювало
• перевірити дозволи папок та php-fpm / nginx, без кореневих проблем і підпапок проблеми однакові
• перевірте посібник php-fpm для інтерпретації коду помилки, його не вдалося знайти
• увімкніть журнал доступу php-fpm, виявив, що URI запиту був правильним, але 404 повернуто
• спробуйте увімкнути режим дозволу / налагодження для php-fpm, не вдалося, файл журналу помилок завжди порожній

Так що я повинен був спробувати останній засіб, так як коренева папка PHP працює і вкладені папки були, єдина істотна відмінність між ними, крім rootє кореневої папка використовується $request_filenameвикористовується і підпапки місця $document_rootі $fastcgi_script_name, таким чином , я змінив настройки вкладеної розташування , щоб відповідати тим кореневій папці.

Тоді це спрацювало ... Я досі не впевнений, чому це працювало. Тому що, коли я перевіряю протокол доступу php-fpm, я бачу той самий URI, один був 404, а другий - 200.

Єдина відмінність полягала в конфігурації. Оскільки вони дають однаковий результат, я не знаю, чому результат вийшов інакше.

У будь-якому випадку я вирішив розмістити свої 2 центи тут, сподіваюся, це допоможе.

PS: Я дуже сподіваюся, що PHP надасть кращі повідомлення про помилки та багатослівний режим, тому що це насправді неприємно не в змозі виокремити проблему, і немає можливості побачити докладний вихід та інформацію про налагодження.

Спробуйте додати кореневу директиву у ваше місцезнаходження.

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