Перейти к содержимому
BXWiki

Меню окружения и службы - что где лежит и как перезапустить

Разбираемся в устройстве веб-окружения: какие службы поднимают сайт, где лежат его файлы и почему настройки правят через меню, а не редактором.

Решение

Открываем меню окружения:

Окно терминала
/root/menu.sh
# пункты меню меняют настройки и переписывают конфигурации служб сами
# правка тех же файлов руками теряется при следующем действии меню

Меню - это не удобная обёртка, а полноправный хозяин конфигураций. Оно перезаписывает файлы служб целиком, поэтому ручная правка живёт ровно до первого действия в меню, а не до обновления окружения.

Смотрим службы, от которых зависит сайт:

Окно терминала
systemctl status nginx httpd bx-php-fpm mysqld --no-pager | grep -E 'Active|●'
systemctl status memcached push-server-sub --no-pager | grep Active
# сайт поднимают несколько служб сразу: веб-сервер, процессы PHP, база

За работу сайта отвечает не одна служба, а целая цепочка. Перезапуск веб-сервера при проблеме в процессах PHP ничего не меняет, и разбор начинается с того, чтобы понять, какое звено молчит.

Находим файлы сайта и журналы:

Окно терминала
ls -d /home/bitrix/www /home/bitrix/ext_www/*     # основной сайт и сайты пула
ls /etc/nginx/bx/site_avaliable/                  # конфигурации сайтов
ls /var/log/nginx/ /var/log/php-fpm/ /var/log/mysqld.log
# у каждого сайта пула свой журнал: имя файла совпадает с именем пула

Расположение файлов одинаково на всех установках этого окружения. Знание трёх путей - сайты, конфигурации, журналы - закрывает большую часть вопросов «а где это посмотреть» без поиска по всему диску.

Перезапускаем и проверяем:

Окно терминала
systemctl restart bx-php-fpm && systemctl status bx-php-fpm --no-pager | head -5
curl -sI https://example.com/ | head -3
tail -20 /var/log/php-fpm/bx0-error.log

После перезапуска смотрят состояние службы и ответ сайта, а не только отсутствие ошибки в консоли. Служба, поднявшаяся с прежней конфигурацией из-за опечатки, выглядит здоровой ровно до первого запроса.

Обновление окружения возвращает все его файлы к своему виду. Всё, что вы правили руками в конфигурациях служб, исчезнет, а сайт при этом продолжит работать - и связать пропажу настройки с обновлением получается далеко не сразу.

Состав служб стоит знать до аварии, а не во время неё. Ночной разбор, начатый с вопроса «а что здесь вообще запущено», занимает вдвое больше времени и обычно заканчивается перезапуском всего подряд.

Свои настройки веб-сервера кладут в отдельный файл включения. Окружение оставляет для этого место, и такие правки переживают и меню, и обновление.

Типичные проблемы

Правка конфигурации исчезла.

Файл переписан меню окружения либо его очередным обновлением. Свои правки кладут в отдельный файл включения рядом.

Перезапуск не помогает.

Перезапущена не та служба из всей цепочки. Сайт поднимают веб-сервер, процессы PHP и база данных вместе.

Служба запущена, а сайт не отвечает.

Она поднялась со старой конфигурацией из-за ошибки в новой. Состояние службы проверяют вместе с ответом самого сайта.

Журналов нет по знакомому пути.

Сайты пула пишут в свои отдельные файлы журналов. У каждого сайта окружения свой собственный набор.

После правки меню сломался второй сайт.

Действие меню применилось сразу ко всему пулу сайтов. Настройки конкретного сайта задают в его разделе меню.

Частые вопросы

Можно ли вообще не пользоваться меню?

Можно, но тогда окружение перестаёт быть окружением: сертификаты, копии и пулы придётся вести руками. Проще принять его правила.

Какую службу перезапускать после правки кода?

Обычно никакую: код читается на каждом запросе. Перезапуск нужен после смены настроек PHP или его версии.

Где смотреть, что именно сломалось?

В журнале той службы, которая отвечает за подозрительное звено. Три каталога журналов закрывают почти все случаи.

Почему в пуле у каждого сайта свои процессы?

Так сбой одного сайта не роняет соседей и виден в его собственном журнале. Это же позволяет задать им разные пределы.

Смежное

Первоисточник