Mod fcgid error reading data from fastcgi server referer

Причины этих ошибок могут быть разные, от неправильных прав на файлы до неполной загрузки файла на сервер, не правильно написанного скрипта и неправильного режима передачи файла ASCII/Двоичный. Иногда бывает проблема кроется в переводе строк Windows формата, в этом случае может помочь команда col -bx <input_file> output_file (скобки обязательны!) или редактор notepad++ «Конверсия конца строки«.

Но когда mod_fcgid в целом работает нормально, а «Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: …» и «Premature end of script headers: php-fcgi-wrapper, referer: …» продолжают регулярно появляться в error_log, при этом php_errors.log и /var/log/httpd/suexec.log не предоставляет никакой дополнительной информации, то копать нужно глубже — /var/log/messages или /var/log/kernel.log.

Chapter 1. Connection reset by peer: mod_fcgid: error reading data from FastCGI server

Если увеличение значений в FcgidProcessLifeTime, FcgidIOTimeout, FcgidIdleTimeout, FcgidBusyTimeout, не решает проблему, тогда нужно смотреть, а не используются ли PHP акселераторы типа APC. Например при использовании opcache в PHP 7 установка PrestaShop 1.7 обламывалась с ошибкой «Connection reset by peer: mod_fcgid: error reading data from FastCGI server«, в php.ini была указана директория для дополнительного кеширования байткода «opcache.file_cache=/var/www/.tmp«, но после того, как «;opcache.file_cache=/var/www/.tmp» была закомментирована — проблема исчезла.

Section 1. Причина №1 — неправильные «чмоды»

Основной причиной, как правило, появления этой ошибки может быть нехватка прав/полномочий на выполнение FastCGI скрипта, РНР в нашем случае.

Права на домашний каталог юзера в котором лежат файлы сайта должны быть 0755 и не меньше, а иначе будет «форбайден» (НТТР 403: 13PermissionDenied — Httpd Wiki), на файл же выполняющий обработку (онже FcgidWrapper) CGI скриптов «чмоды» (chmod) как минимум 750.

Если не помогло, смотрим иные варианты…

Section 2. Причина №2 — нахватка системных ресурсов

Например, первые ошибки mod_fcgid мы получили в error_log «Fri Mar 08 13:42:10 2013«:

Тогда открываем /var/log/messages или /var/log/kernel, находим системные события происходившие в упомянутое выше время вплоть до секунды и смотрим что же там творилось до и после ошибки php-cgi: http://pastebin.com/Gz5ccSNV

Как видим OOM Killer (oom-killer) начал прибивать процессы уже когда памяти совсем не осталось. OOM Killer — это реализация «Out of memory Killer» на уровне ядра Linux.

Виртуальной памяти (swap) в системе может быть немеряно, разумеется в пределах адресации HDD, а вот оперативной (RAM-ы) вполне ограниченное её количество. Бывают ситуации когда «чилды» (форки) процессов системы поедают ее всю (swap + RAM), и тут OOM Killer начинает среди процессов, кроме kernel init и threads, такой, который по его (oom-killer) мнению является самым ущербным (badness) и начинает его убивать.

В примере выше как раз возникла именно такая ситуация, когда «Free swap = 0kB» процессами (их чилдами/форками httpd-олигархов) httpd и php-cgi съедена вся память включая файл подкачки, «Swap is 100% used» и «Memory is 99% used» — обычно в таких ситуациях система уходит в нирвану и прекращает отвечать/реагировать на внешние команды.

Для решения проблемы поедания памяти рекомендуется снизить число чилдов (CHILDREN) апача и PHP, если PHP_FCGI_CHILDREN больше 2. Понизить значение PHP_FCGI_CHILDREN, а в случае использования PHP акселераторов типа APC и т.д. установить PHP_FCGI_CHILDREN = 0 ибо как сказано в секции «Special PHP considerations» официального мана mod_fcgid, чтоPHP акселератор APC не в состоянии расшаривать свой кэш для PHP модуля mod_fcgid если mod_fcgid/PHP использует управление процессами! Про иные акселераторы ничего не сказано, но всё же если используются любые акселераторы, то лучше управление процессами оставить на совести httpd демона.

Второй способ побороть ошибки «Connection reset by peer: mod_fcgid: error reading data from FastCGI server» и «Premature end of script headers: php-fcgi-wrapper» — это не устанавливать слишком высокое значение в PHP_FCGI_MAX_REQUESTS, которое по умолчанию равно = 500. Вместе с этим использовать директиву FcgidMaxRequestsPerProcess, значение которой должно быть <= PHP_FCGI_MAX_REQUESTS — т.е. если PHP_FCGI_MAX_REQUESTS = 1000, то и значение FcgidMaxRequestsPerProcess должно быть = 1000 или меньше, по умолчанию количество запросов отправляемых в php-cgi не контролируется, т.е. FcgidMaxRequestsPerProcess = 0.

В некоторых случаях помогает увеличение РНР лимита в php.ini, в директивах «max_execution_time = 180«, «max_input_time = 120» и «default_socket_timeout = 180«, а также установкой «FcgidIOTimeout 300» и «FcgidBusyTimeout 500» в vi /etc/httpd/conf/httpd.conf или же конфиге виртуального хоста — разумеется под каждые конкретные условия значения подбираются экспериментальным путём.

Следующим шагом будет выбор стратегии выделения памяти (OVERCOMMIT_GUESS (0), OVERCOMMIT_ALWAYS (1), OVERCOMMIT_NEVER (2)) отличной от стратегии по умолчанию. По умолчанию sysctl -w vm.overcommit_memory=0 система пытается оценить объем свободной памяти, а на практике же удовлетворяет все запросы к памяти до момента её полной утечки, после чего вызывает упомянутый выше OOM Killer (oom-killer) уже тогда, когда система ушла в нирвану «Free swap = 0kB», «Swap is 100% used» и «Memory is 99% used».

vm.overcommit_memory=1 почти тоже что и = 0, только теперь уже система не пытается оценивать объем свободной памяти, а делает вид, что её всегда хватает до момента её полной утечки. vm.overcommit_memory=2 запретит выделять больше памяти чем имеется в файле подкачки и больше оперативной памяти в процентном соотношении указанном в параметре vm.overcommit_ratio=?. Также можно вырубить эвристический поиск ущербного процесса для убивания, по умолчанию vm.oom_kill_allocating_task=0 (OOM Killer) сканирует весь список задач и на основе своего эвристического алгоритма выбирает процесс для убивания, что отнимает дополнительные ресурсы системы. Значение выше 0 запрещает сканировать список задач и говорит «OOM Killer-у» уничтожать любой процесс запросивший больше РАМ-ы чем имеется в наличии.

Для изменений на постоянной основе добавим в /etc/sysctl.conf. Ещё как вариант можно сделать ещё один файл подкачки, на случай вонючий:)

Chapter 3. mod_fcgid: can’t lock process table in pid

Это сообщение «mod_fcgid: can’t lock process table in pid» (mod_fcgid: не может заблокировать таблицу процессов в pid) может возникать тогда, когда регулярно используется команда «apachectl graceful» — т.е. перезапуск без разрыва текущих соединений, а её выполнение попадает во время интенсивного использования/нагрузки сервера.

Chapter 4. mod_fcgid: can’t apply process slot

«mod_fcgid: can’t apply process slot» — mod_fcgid не может выделить слот для процесса…

Section 1. Причина №1 — проблемы сегментации

В лог файл виртуального хоста получили «[warn] [client 78.159.53.233] mod_fcgid: can’t apply process slot for /var/www/user/php/php-cgi-wrapper, referer: https://www.google.com.ua/«, а в лог файл самого сервера множественные «[crit] (22)Invalid argument: ap_queue_pop failed«.

Ошибкой «Invalid argument: ap_queue_pop failed» в лог файл /var/log/httpd/error_log нагадило мегов на 300 с лишним за какие-то считанные минуты. Этой ошибке предшествовали сообщения «[alert] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread» и «[notice] child pid 2839 exit signal Segmentation fault (11) Error in my_thread_global_end(): 1 threads didn’t exit«.

На ibm.com рекомендовалось увеличить значение «sysctl -w kernel.threads-max=120000» (по умолчанию 3525 в CentOS 6 и 7877 в CentOS 5) и уменьшить «stack size» с 10240 кб до «ulimit -s 256«.

Размер для каждого потока «thread» равен размеру «stack size», а если Apache запущен как Workerи завышены значения MaxClients, MinSpareThreads, MaxSpareThreads и ThreadsPerChild, в условиях нехватки памяти, то получим «[alert] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread Error in my_thread_global_end(): 1 threads didn’t exit»

Можно увеличить kernel.threads-max, но «stack size» лучше оставить как есть, а иначе на некоторых страницах сайта это может вызывать ошибку «exit(communication error), get unexpected signal 11«! Однако принимая во внимание предыдущий абзац, «stack size» можно попробовать урезать в 3-5 раза или же урезать ThreadsPerChild если продолжаем получать «Resource temporarily unavailable: apr_thread_create: unable to create worker thread«.

Установить ограничение для «stack size» на постоянной основе можно в конф. файле /etc/security/limits.conf:

В примере выше мягкий лимит на «stack size» для всех установлен в 2 МБ, а для пользователя apache ограничен жестким лимитом в 5 МБ. После изменения лимитов с помощью «ulimit -s 256» нужно остановить и снова запустить сервер «service httpd stop && service httpd start«, чтобы изменения вступили в силу, изменения в /etc/security/limits.conf вступят в силу после перезагрузки ОС!

Section 2. Причина №2 — проблема конфигурации

…»mod_fcgid: can’t apply process slot» может быть связана не только с ошибками сегментации, но и с другими причинами такими, как например конфигурация самого mod_fcgid. Рядом с ошибкой «mod_fcgid: can’t apply process slot» граничит и «apache https 503» (ака «Service Unavailable»).

Основную погоду делают параметры:

• FcgidMaxProcesses — максимально допустимое число php-cgi процессов запущенных одновременно;
• FcgidMaxProcessesPerClass — максимально допустимое число php-cgi процессов для каждого класса.

PerClass-ом в Апаче, имхо … как я понимаю, считается базовый хост и все его виртуальные хосты. Значит, если FcgidMaxProcessesPerClass 2, а виртуальных хостов у нас 15 + 1 базовый хост, то в итоге получаем 32 php-cgi процесса, но если FcgidMaxProcesses (1000 по умолчанию) будет ниже 32, то в итоге в лог можем получить «mod_fcgid: can’t apply process slot», а в браузер «503 Service Unavailable».

В некоторых случаях (зависит от нагрузки) значение FcgidMaxProcessesPerClass должно быть не меньше 3-5.

Chapter 5. exit(communication error), get unexpected signal 11

Эта ошибка результат уменьшения «stack size»:

Premature end of script headers / exit(communication error), get unexpected signal 11 в некоторых случаях может возникать из-за PHP акселераторов типа APC, обычно отсутствует если PHP работает «Как модуль APACHE».

Примечательно, что данная ошибка может проявляться только на некоторых страницах, обычно больших по размеру, где, например, может быть много кода раскрашиваемого Geshi плагином. Часто такие страницы создают большую нагрузку на ЦП и превысив всевозможные лимиты вызывают segfault.

Chapter 6. user mismatch (daemon instead of www)

Связанные ошибки:

Ошибка вызвана несовпадением имени пользователя указанного в директиве AP_HTTPD_USER, имя которого можно узнать выполнив «suexec -V«, с именем пользователя, которое указано в /var/www/conf/httpd.conf.

В данном случае AP_HTTPD_USER для suexec = www, а имя указанное в httpd.conf = daemon. Решение: в конфиге /var/www/conf/httpd.conf, в директивах User и Group указать имя www вместо daemon.

Chapter 7. mod_fcgid: couldn’t bind unix domain socket /var/www/logs/fcgidsock/29944.19

Сопутствующие ошибки:

Решается сменой прав на каталог «chmod 777 /var/www/logs/fcgidsock/» или же сменой каталога директивой FcgidIPCDir

…

Если есть ещё какие вопросы по другим ошибкам mod_fcgid, то пишем в комментарии…

Chapter 8. Ссыль по теме:

• mod_fcgid — Apache HTTP Server
• Documentation for /proc/sys/vm/*

Stuck with the Error reading data from fastcgi server: Plesk? We can help you.

Generally, we come across this error due to corrupted WordPress plugins.

As part of our Server Management Services, we assist our customers with several Plesk queries.

Today, let us discuss how to resolve this error.

Error reading data from fastcgi server: Plesk

Recently, one of our customers came across this error on at least 3 of the domains on his server. The error message is like this:

Connection reset by peer: mod_fcgid: error reading data from FastCGI server

The major symptom of this error includes:

• WordPress is installed on the Plesk server. However, login to the WordPress admin page is slow.
• Errors in /var/www/vhosts/system/example.com/logs/error_log:

[warn] [client 203.0.113.2] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: https://example.com/wp-admin/
[error] [client 203.0.113.2] Premature end of script headers: edit-comments.php, referer: https://example.com/wp-admin

• Stracing Apache processes shows the following:

# for fn in `ps fax | grep -i /usr/sbin/httpd | grep -v grep | awk '{ print $1 } '` ; do strace -fF -tT -s102400 -o /tmp/strace.log -p $fn & done

# grep plugins /tmp/strace.log | grep such
32335 02:12:05 lstat("/var/www/vhosts/example.com/httpdocs/test_rp/wp-content/languages/plugins/woocommerce-en_US.mo", 0x7ffe87108a60) = -1 ENOENT (No such file or directory) <0.000015>

Corrupted WordPress plugins can be the cause of this error. In the example above, the WooCommerce plugin is the cause.

How to solve this?

Moving ahead, let us see how we can fix this error in different scenarios:

• Initially, we log in to Plesk
• Then we deactivate one by one all plugins for the website at Domains > example.com > WordPress > Plugins until we fix it.
• Eventually, we can Re-install or delete the plugin we have identified.

On the other hand, if we find that the permissions on the file /var/www/cgi-bin/cgi_wrapper are incorrect, we can fix it via command-line.

To do so, we connect to the server via SSH

Then we correct the permissions:

# chown root:root /var/www
# chmod 0755 /var/www
# chown -R root:root /var/www/cgi-bin
# chmod 0755 /var/www/cgi-bin
# chmod -R 0755 /var/www/cgi-bin/cgi_wrapper

[Need help with the fix? We are available 24*7]

Conclusion

To conclude, in most cases, this error occurs when there are Corrupted WordPress plugins. Today, we saw how our Support Techs fix this for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

13 ответов

<VirtualHost *:80>
.......
<IfModule mod_fcgid.c>
FcgidBusyTimeout 3600
</IfModule>
</VirtualHost>

(104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
Premature end of script headers: phpinfo.php

ls -la /var/www
drwxrws---  5 www-data     www-data     4096 Oct  7 11:17 .

--enable-cgi

--enable-fastcgi

--enable-fastcgi

PHP 5.2.17 (cgi-fcgi) (built: Jul  9 2013 18:28:12)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

FcgidBusyTimeout 600

sudo apt-get install php5-cgi

sudo yum install php5-cgi

$ cd /var/log/apache2/
$ less suexec.log

[2015-03-22 10:49:00]: directory is writable by others: (/var/www/cgi-bin/cgi_wrapper)
[2015-03-22 10:49:05]: uid: (10004/gb) gid: (1005/1005) cmd: cgi_wrapper

$ chown root:root /var/www/cgi-bin/cgi_wrapper
$ chmod 755 /var/www/cgi-bin/cgi_wrapper
$ shutdown -r now

Здравствуйте!

Все время существования сервера у меня каждый день имеется ~ 30 вот таких вот ошибок в еррор логах:

[Fri Mar 04 15:52:04 2016] [warn] [client 85.94.17.79] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: site.ru/category/post
[Fri Mar 04 15:52:04 2016] [error] [client 85.94.17.79] Premature end of script headers: kama_postviews.php, referer: site.ru/category/post

Они вылетают на случайных страницах и Premature end of script headers: kama_postviews.php — не всегда этот файл, это может быть и index.php и еще что-то

Логи пересматривал кучу раз, абсолютно все которые есть на сервере — причину никак выявить не могу. Конфиг fcgid.conf менял тыщу раз — никаких результатов это не дает. Т.е. эта ошибка (в браузере отображается как 500) — какая-то неуловимая и рандомная, вообще не от чего не зависит… Появляется она так же в случайный промежуток времени — т.е. ошибки эти не только утром, днем или вечером, а равномерны в течении дня. Так же нет никакой аномальной нагрузки на сервер при появлении этой ошибки.

Если перевести эти ошибки в % относительно просмотренных страниц — получается ~ 0.03% Это не критично и никаких жалоб мне не поступает, но очень раздражает наличие этой ошибки в error логах — если бы не она, то этот лог был бы пустой

Так же нет никаких зависаний при появлении ошибки. Т.е. я кликаю на ссылку, потом на другую и в один момент бац — мгновенно отдается ошибка 500, т.е. я даже не жду генерации страницы. Затем жму обновить страницу и все нормально — страница грузится без каких-то тормозов.

Вопрос: У вас нет никаких идей из-за чего это может быть и как с этим бороться? Или 0.03% того не стоят и можно не обращать на это внимания?

Дополнительно:
Я на 1ом каком-то сайте однажды столкнулся с такой же ошибкой: бродил по сайту и тут бац, после клика по ссылке вылезла ошибка 500, но не прошло и секунды как страница сама обновилась и все работало нормально.

Вы не знаете что это за фишка такая, что страница сама обновилась как только вылезла ошибка 500?

(104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server

Set up:

• Plesk Obsidian 18.0.28
• Centos 7

Like any error that pops up, the real check is how do you react?

• Keep and calm and investigate — even if colleagues are stressed out; 
• Grab a stress ball and work on it hard; or
• Join and stressed out party and lose perspective.

I haven’t seen this one before.  A quick search through Google and I discovered a solution on Virtualmin.  However, they write about a migration process which for us wasn’t happening.  Second, they point to a directory fcgi-bin.  A quick look using shell ls command and again not us.  But the essence of what they wrote about pointed me in the right direction.

In Plesk, I performed the following steps:

• Respective domain.com;
• Hosting settings; and
• Then scrolled to the bottom and clicked Apply

Checked the front-end of the offending site, and back up and running.

Logs

Looking through the error logs on the server, not that much more was shown from the original error:

• [Thu Aug 06 10:25:14 2020] [warn] [client xxx.xx.xx.xxx] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
• [Thu Aug 06 10:25:14 2020] [error] [client xxx.xx.xx.xxx] Premature end of script headers: index.php

So I needed to alter the mod_fcgi through using FcgidBusyTimeout.  This can be applied a couple of ways.

1. Through Plesk:
   1. Respective domain.com;
   2. Click on PHP Settings;
   3. Scroll to the bottom and in the input box for Additional directives, add 

      1. FcgidBusyTimeout=3600

   4. Click Apply
2. Using Shell:
   1. Open your directory of the domain 
   2. cd /var/www/vhosts/your-domain.com
   3. Open .htaccess file using

      1. vi .htaccess

   4. Add the following lines

      1. <IfModule mod_fcgid.c>
         FcgidBusyTimeout 3600
         </IfModule>

   5. Save [esc]wq!

With either, when you go back to the front end, potentially on your first refresh you might see 502 error.  No issue, refresh again and the error should be gone and your site back up.

<VirtualHost *:80> ....... <IfModule mod_fcgid.c> FcgidBusyTimeout 3600 </IfModule> </VirtualHost> 

 (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server Premature end of script headers: phpinfo.php 

 ls -la /var/www drwxrws--- 5 www-data www-data 4096 Oct 7 11:17 . 

 --enable-cgi 

 --enable-fastcgi 

 --enable-fastcgi 

 PHP 5.2.17 (cgi-fcgi) (built: Jul 9 2013 18:28:12) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies 

 FcgidBusyTimeout 600 

В версиях CentOS suexec компилируется для запуска только в / var / www. Если вы пытаетесь установить DocumentRoot где-то еще, вам нужно перекомпилировать его – ошибка в журнале apache: (104) Сброс соединения через peer: mod_fcgid: ошибка чтения данных с сервера FastCGI Преждевременный конец заголовков скриптов: php5.fcgi

  sudo apt-get install php5-cgi 

  sudo yum install php5-cgi 

Проверьте / var / lib / php / session и его разрешения. Этот каталог должен быть доступен для записи пользователем, чтобы сеанс можно было сохранить

Как уже упоминалось, это может происходить из-за проблем с обработчиком fcgi. Если вы используете suexec – не забудьте проверить, включен ли в этот модуль этот модуль.

 $ cd /var/log/apache2/ $ less suexec.log 

 [2015-03-22 10:49:00]: directory is writable by others: (/var/www/cgi-bin/cgi_wrapper) [2015-03-22 10:49:05]: uid: (10004/gb) gid: (1005/1005) cmd: cgi_wrapper 

 $ chown root:root /var/www/cgi-bin/cgi_wrapper $ chmod 755 /var/www/cgi-bin/cgi_wrapper $ shutdown -r now