failed to restart php fpm service unit php fpm service not found
Почему не стартует php7.2-fpm после ребута?
Jan 28 05:07:26 vm-83a6fe5c systemd[1]: Starting The PHP 7.2 FastCGI Process Manager.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Start operation timed out. Terminating.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: Failed to start The PHP 7.2 FastCGI Process Manager.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Unit entered failed state.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Failed with result ‘timeout’.
Александр Владимирович, давайте поясню, раз не только у вас такая штука, как наблюдаю в комментариях.
Более полное описание ситуации: проблема есть только при старте системы. Если перезапустить сервис на работающей машине все достаточно быстро поднимается.
Пример как отлавливать баги в случае старта сервисов из под systemd:
Для понимания причины добавляем в вызов запуска сервиса слежение за ним через strace с записью лога в файл. Для этого достаточно добавить полный путь до этой утилиты и набор ключей в строку запуска сервиса, например:
Собственно так можно дебажить любое приложение. После перезагрузки смотрим в указанный нами файл, чтобы понять на чем сломалось.
Далее конкретно про наш случай.
Выполнение команды запуска ломается на запросе getrandom. Если выставить задержку старта процесса, то данный запрос отрабатывает. При этом, чем дальше отложить старт сервиса, тем быстрее он работает.
Данный вызов напрямую связан с системными вызовами random/urandom и количеством энтропии в системе. Очевидно, что от времени старта работа системных вызовов не должна меняться, хотя и стоит проверить последовательность старта сервисов в systemd. Значит это энтропия.
На старте смотрим количество
и получаем бодрый нолик в момент первого запроса getrandom, что и является причиной сбоя. Энтропия нарастает медленно, а она нужна веб-серверу для осуществления криптографических функций. В установленный таймаут вызов не успевает набрать необходимого числа случайных данных из-за низкой энтропии. Как решение можно использовать пакет haveged. Более того, мы приняли решение добавить его в наш образ по молчанию и проблема в ближайшее время перестанет возникать на новых виртуальных серверах.
Выдержка из статьи на тему энтропии:
Linux уже предоставляет довольно качественные случайные данные при помощи вышеописанного ПО, но поскольку автономные компьютеры обычно не имеют клавиатуры или мыши, генерируемая на них энтропия гораздо ниже, поскольку создаётся диском или I/O сети. Очень немногие автономные машины имеют специальное аппаратное обеспечение для ГСЧ, поэтому существует несколько пользовательских решений для создания дополнительной энтропии при помощи аппаратных прерываний, т.к. некоторые устройства (например, звуковые и видеокарты) создают больше так называемого «шума», чем жёсткий диск. К сожалению, даже это не решает проблему виртуальных серверов, т.к. там генерировать энтропию практически нечему. Но тут на помощь приходит инструмент haveged. Основанный на алгоритме HAVEGE (а ранее – на его библиотеке), haveged позволяет генерировать случайные данные, руководствуясь изменениями во времени выполнения кода на процессоре.
[РЕШЕНО] Error: php-fpm restart failed vestacp
Сегодня рассмотрим решение ошибки «Error: php-fpm restart failed vestacp» в VestaCP после обновления PHP.
Недавно я писал про обновление интерпретатора PHP c версии 7.2 на версию 7.3 на Ubuntu Server с установленной админ-панелью VestaCP. Кому надо можете почитать, вот ссылка. Там кстати разбирается ошибка 500 после обновления на PHP7.3.
Ну а сегодня рассмотрим ошибку в самой админ-панели VestaCP. Данная ошибка появляется если вы хотите добавить новый домен в вашу панель. Вот что вылезло у меня при попытке добавить новый домен:
Error: php-fpm failed
Решение ошибки Error: php-fpm restart failed vestacp
Давайте же избавимся от этой проблемы. Для начала заходим на наш сервер при помощи SSH, как это сделать для вашей ОС можете найти в просторах интернета.
Далее нам необходимо удалить символическую ссылку php-fpm из директории /etc/init.d/ и создать новую:
Делаем рестарт PHP на всякий случай:
sudo service php-fpm restart
Теперь заходим в админ-панель VestaCP и пробуем добавить новый домен. На этот раз ошибка «Error: php-fpm restart failed vestacp» появляться не должна.
Если есть вопросы, то пишем в комментариях.
Также можете помочь проекту, заранее всем СПАСИБО.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
I’m trying to get a Homestead Improved Vagrant VM instance running on Windows. See Homestead Improved on Github. I’m following this easy introduction: https://www.sitepoint.com/quick-tip-get-homestead-vagrant-vm-running/
Machine boots and is ready. Then provisioner is running. Then I get the follwoing error message:
==> default: Failed to restart php7.0-fpm.service: Unit php7.0-fpm.service not found.
The SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed. The output for this command should be in the log above. Please read the output to determine what went wrong.
Any hints what to do?
1 Answer 1
This has been fixed on the repo-level, and should never happen again if you run git pull inside your homestead improved cloned folder (but outside of the VM, not SSH-ed into it). If your machine is already running, you might have to apply the steps below, too. But new machines (so new clones of Homestead Improved) will not have this happen any more). Explanation of what happened is here.
@daniel-sixl please try to re-download/re-clone and start from scratch, everything should be working just fine now.
Edit: added more detailed instructions for people very new to it all.
Ok, so what you need to do is, once you’re in the sites-available folder, edit the homestead.app file. Something like sudo vim homestead.app will do just fine, it’ll open a basic text editor (that’s quite nightmarish to use when you’re new at it, so just be patient 🙂 ) Sudo is important, because you are editing a file that only an admin has access to.
Once you’re «in», do the following:
The new configuration should now take effect, and everything should start working.
Drupal Русскоязычное сообщество
поставил на Debian 8 сервер Nginx + PHP7 + PHP7.0-FPM, статика работает, а обращение к php-файлам даёт ошибку 502.
почитав /var/log/nginx/site.com.error.log я понял что ошибка с сокетом:
2016 / 08 / 19 05:05: 32 [ error ] 1392 #1392: *15 connect() to unix:/var/run/php7.0-fpm.sock failed (111: Connection refused) while connecting to upstream, client: 88.88.88.88, server: site.com, request: «GET /index.php HTTP/1.1», upstream: «fastcgi://unix:/var/run/php7.0-fpm.sock:», host: «site.com»
но в интернете пояснили, что возможно не запущен процесс обработки запросов, то есть php7.0-fpm, я проверил так и убедился что пхп-фпм не запускается:
Лучший ответ
Комментарии
может поиск процесса неправильный. вот так что-то видно
вот код /etc/init.d/php7-fpm
# Author: Ondrej Sury
# Adapted to php7-fpm by @B..joh..en
# Load the VERBOSE setting and other rcS variables
. / lib / init / vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. / lib / lsb / init-functions
# Don’t run if we are running upstart
if init_is_upstart; then
exit 1
fi
#
# Function to check the correctness of the config file
#
do_check ( )
<
/ usr / local / lib / php7-fpm-checkconf || return 1
return 0
>
pool настраивали?
По правде говоря у меня с сокетом тоже траблы были и было лень разбираться и запускал через tcp
В бложике есть устаревший материал, но настройки fpm и пула там в принципе актуальны.
pool не упоминался в мануалах, я не знаю что это такое
вот как настроена связка Nginx + php7.0-fpm
pid = / var / run / php7-fpm.pid
error_log = / var / log / php7-fpm. log
include = / usr / local / php7 / etc / php-fpm.d /*.conf
# cat /usr/local/php7/etc/php-fpm.d/www.conf
[www]
user = www-data
group = www-data
listen = /var/run/php7.0-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
вот конфиг хоста site.com
access_log / var / log / nginx / site.com.access. log main;
error_log / var / log / nginx / site.com.error. log ;
/ \. <
deny all;
access_log off;
log_not_found off;
>
>
в этом файле я эту строку правил и еще по-моему одну из эти раскомментировал:
user = www-data
group = www-data
ну теперь я исправил слушать сокет:
listen = /var/run/php7.0-fpm.sock
рестарт сервиса
service php7-fpm restart
ПРОБЛЕМ НЕ РЕШИЛАСЬ
снёс php7 со всеми зависимостями, и php тоже снес так
apt-get purge php7
apt-get remove php*
и поставил php5-fpm одной строкой из одного мануала на моем сайте.
подкорректировал /etc/nginx/fastcgi_params (изменив адрес сокета на /var/run/php5-fpm.sock),
и сайт нормально стал работать
спасибо за ссылку. пытаюсь заново на новой впсине.
вообще меня смущала и сейчас опять появляется следующая проблема:
после запуска команды автора http://kubanga.ru/obnovlenie-php-56-do-php-7-v-debian-jessie-na-vds-digi.
«Устанавливаем php7
apt-get install php7.0-fpm php7.0-gd php7.0-pgsql php7.0-apcu php7.0-curl»
все ставится но в конце вот что сообщвет:
но ввсе вроде есть, просто вопрос сконфигурировано ли?
что тут не так? пользователя я создал. группу ему дал
в смысле в одну? я проверял, скопированные строки вставлял в sublime и с пробелами было все нормально.
в debian 7 был apc, а в debian8 apcu
в конфигурации apc
Когда с седьмого дебиана на восьмой переходил было неожиданностью)
после установки сервера по неполной инструкции, я увидел ошибку
The website encountered an unexpected error. Please try again later.
просмотрев логи ошибок nginx (файл ошибок сайта не был прописан в хосте, поэтому именно нгиникс):
я стал гуглить и понял, что надо доставить пакеты работы php7.0-fpm с базами mysql:
после установки модулей для работы с бд, я опять увидел то же сообщение и в ошибках нгиникс были новые ошибки:
PHP message: Error: Class ‘DOMDocument’ not found in core / lib / Drupal / Component / Utility / Html.php on line 284
это предполагает установку php7.0-xml как я понял
после всех этих действий мой сайт открылся на Debian 8 Nginx + PHP7.0-FPM + mysql
спасибо михаил.спейс за рабочий мануал
Я в с соседней теме писал про php7.0-xml, тоже была такая беда.
Try to start php-fpm7.0 #392
Comments
makz27 commented Dec 9, 2016
Since the 1.0.0 image, when i provision the vm the script try to start php-fpm7.0 but it doesn’t exist because now it’s php-fpm7.1
==> homstead: Failed to restart php7.0-fpm.service: Unit php7.0-fpm.service not found.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
makz27 commented Dec 9, 2016
I forced the homestead update to 4.0.0 it worked, thank you.
svpernova09 commented Dec 9, 2016
If you’re using Homestead per project or have homestead in a global composer.json You’ll want to make sure you have it set to «^4.0»
mtpultz commented Dec 14, 2016 •
@svpernova09 apparently if we aren’t quite ready to adopt PHP 7.1 we can use v3.1.0 of laravel/homestead, but this seems to cause the same kind of error:
Do you have any suggestions? I’ve followed that post’s instructions for a per project installation.
svpernova09 commented Dec 14, 2016
You’ll need to lock the version of the box down to a previous version by adding
mtpultz commented Dec 14, 2016 •
svpernova09 commented Dec 14, 2016
Box 1.0.0 & 1.0.1 are both PHP 7.1. 0.6.0 Was the last version with PHP 7.0.
giovannipds commented Dec 20, 2016
dPhantum commented Nov 9, 2017
I tried above and nothing worked and was getting error:
homestead-7: Failed to restart php7.2-fpm.service: Unit php7.2-fpm.service not found.
After a little digging..
There is an issue in the [homestead-install]/scripts/homestead.rb script that does not validate if the script exists prior to adding it to the execution stack. It blindly adds it.
If you edit that file and remove for the version of php that does not exist for you.
Verfiy in linux if not installed by:
and you don’t see that version installed it is complaining about (i.e. php7.2-fpm)
Then if you edit the file scripts/homestead.rb and remove the references, it will proceed and complete the data creation scripts, which is where it fails before running them.
You see the blind assignment for example
line 231:
s.inline = «sudo service nginx restart; sudo service php5.6-fpm restart; sudo service php7.0-fpm restart; sudo service php7.1-fpm restart; sudo service php7.2-fpm restart;»
In my case it is 7.2, so I removed it to look like:
s.inline = «sudo service nginx restart; sudo service php5.6-fpm restart; sudo service php7.0-fpm restart; sudo service php7.1-fpm restart»
line 330:
s.inline = «service php5.6-fpm restart; service php7.0-fpm restart; service php7.1-fpm restart;service php7.2-fpm restart;»
to look like:
s.inline = «service php5.6-fpm restart; service php7.0-fpm restart; service php7.1-fpm restart;»
It will not die for the false reference and you should be able to continue your work, without wasting hours/days trying to look for a solution, when perhaps in a work panic.