Вопрос или проблема
Я заметил, что на моем сервере RHEL 7 на GCP, мои включенные службы (такие как test.service) запускаются только если я останавливаю службу multi-user.target с помощью systemctl. Может ли быть какая-то причина, по которой multi-user.target блокирует процессы?
Я думаю, вы неправильно поняли, что там показано.
-
google-startup-scripts.serviceблокирует все. -
test.serviceожидаетmulti-user.target(без жесткой зависимости, т.е. сWants=или без зависимости и только с порядком). -
Остановка работы для
multi-user.targetпозволяет всем процессам, которые его ожидают, продолжать без его требования (те, у которых есть требование, терпят неудачу).
Остановка или завершение google-startup-scripts.service было бы лучшим подходом. Проверьте, почему это не завершается.
Ответ или решение
Вопрос о том, почему на сервере RHEL 7 в Google Cloud Platform (GCP) включенные сервисы запускаются только после остановки multi-user.target, действительно вызывает интерес. Разберем эту ситуацию детально, опираясь на сведения из вашего описания и используя подход TEA (Theory, Example, Application).
Теория
systemd — это система инициализации и менеджер системных сервисов для Linux-платформ, который использует понятия "юнитов" и "таргетов" для управления состоянием системы. multi-user.target представляет собой логический уровень, который соответствует традиционному уровню инициализации 3 в классических System V, где система работает в многопользовательском режиме без графического интерфейса. В большинстве случаев multi-user.target запускается на одном из последних этапов загрузки, после чего включаются сервисы, не требующие графической оболочки.
Каждый таргет может иметь свои зависимости в виде других юнитов (сервисов), которые должны быть запущены перед ним, либо параллельно. В данной ситуации multi-user.target содержит зависимости, определенные отношением Wants= или Requires=, которые могут создавать цепочки, приводящие к проблемам, если один из сервисов зависает или не завершает свою инициализацию.
Пример
На основании предоставленной вами информации, основная проблема заключается в блокировке, вызванной google-startup-scripts.service. Этот сервис, вероятно, предназначен для выполнения скриптов инициализации, специфичных для окружения GCP. Если он зависает, то все связанные зависимости также оказываются в подвешенном состоянии. Это, в свою очередь, препятствует завершению multi-user.target и, соответственно, блокирует запуск других сервисов, таких как test.service, ожидающих полного завершения инициализации multi-user.target.
Согласно вашему описанию, убийство или остановка multi-user.target неожиданно позволяет продолжить работу зависимым процессам, что указывает на разрыв порядка загрузки. Однако это похоже на обходной путь, а не на решение самой проблемы.
Применение
Наиболее корректным способом решения проблемы будет сфокусироваться на google-startup-scripts.service, поскольку он является непосредственной причиной блокировки. Вам необходимо понять, почему этот сервис не завершает свою работу. Начнем с проверки журналов:
journalctl -u google-startup-scripts.serviceЭто может дать представление о сообщениях об ошибках или других аномалиях, связанных с его выполнением. Возможные проблемы могут включать ошибки в самих скриптах, внешние зависимости, или неправильные конфигурации.
Если в журналах ничего неясно, попробуйте временно отключить этот сервис для диагностики:
sudo systemctl disable google-startup-scripts.service
sudo systemctl stop google-startup-scripts.serviceПосле выключения перезагрузите систему и проверьте, решает ли это проблему с зависанием. Если test.service запускается без проблем, то, вероятно, проблема именно в скриптах или их выполнении.
Следующим шагом может быть ручная проверка скриптов, которые выполняет этот сервис. Посмотрите на их содержимое, попытайтесь воспроизвести шаги по отдельности, чтобы найти точку затыка. Возможным решением может быть внесение корректировок в этот скрипт или создание более детальных логов, чтобы точнее выявить проблемную часть.
Если проблема продолжает оставаться, рассмотрите возможность обратиться к документации GCP или поддержке, так как это может быть связано с обновлениями или специфической конфигурацией вашей среды.
Заключение
Таким образом, для решения данной проблемы требуется систематический подход к диагностике сервисов и корректировке конфигураций. Основополагающим является понимание цепочек зависимостей в systemd и тщательное изучение журналов и скриптов, которые вызывают зависания.