Ярлык к файлу службы systemd не загружен в RHEL9 из-за порядка операций.

RHEL9 с каталогом OPT, подключенным через fstab ….

Установленный IWS создает ярлык в /etc/systemd/system, указывающий на фактический .service файл в каталоге /opt…

Проблема в том, что systemd ЧИТАЕТ каталог /etc до того, как каталог opt завершает монтирование, так что кажется, что файл IWS .service отсутствует и не запускается.

Если я копирую фактический файл службы в путь /etc, все работает хорошо…

Предложения?

Спасибо -R

Уважаемый R,

Ваш вопрос о том, как корректно загрузить файл службы systemd, связан с порядком монтирования разделов в Red Hat Enterprise Linux 9 (RHEL9), поднимает важную проблему. Когда файл службы systemd, необходимый для работы IWS (предполагая, что вы имеете в виду IBM WebSphere или другую подобную систему), находится в каталоге, который монтируется через fstab, система может не успеть его увидеть к моменту, когда завершает чтение отпг. Давайте разберем это более детально и предложим возможное решение.

Теоретическая часть:

В системах Linux, включая RHEL9, порядок монтирования разделов и последовательность операций запуска служб systemd играют ключевую роль в обеспечении правильной работы системы. При запуске системы systemd считывает службы из /etc/systemd/system и запускает их в соответствии с указанными зависимостями и временным графиком. Если одна из этих служб зависит от ресурсов, находящихся на не смонтированном еще разделе, возникнут проблемы с запуском этой службы.

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

Практический пример:

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

Самым простым обходным решением, которое вы уже нашли, является копирование фактического файла службы в каталог /etc/systemd/system, что устраняет зависимость от времени монтирования. Но это не всегда удобно или устойчиво, особенно при обновлениях или изменениях конфигурации.

Применение решения:

Есть несколько возможных решений, которые могут помочь справиться с данной ситуацией без необходимости в копировании файлов вручную:

• Использование After и BindsTo: Добавьте в файл службы директивы After и BindsTo, связанные с opt.mount. Это заставит systemd ждать, пока раздел будет смонтирован.

[Unit]
Description=IWS Service
After=opt.mount
Requires=opt.mount

[Service]
...

• Использование автозагрузки: Отключите начальную загрузку службы и используйте скрипт автозагрузки, чтобы проверить монтирование и запустить службу после монтирования.
  Это можно сделать, создав командный файл в /etc/rc.local или аналогичном месте, который будет проверять, был ли ресурс доступен, и, если он доступен, будет вызвана команда systemctl start your-service.service.
• Загрузка с отложенным запуском: Исправьте времени загрузки вашей службы, заставляя её перезапускаться с задержкой, что потенциально позволит разделу смонтироваться до её запуска.
• Использование initrd: Если это возможно, включите необходимые файлы в initrd, чтобы они были доступны в момент загрузки, но это решение может усложнить процесс поддержки и обновлений системы.
• Локальные изменения.: Создайте и поддерживайте локальную версию файлов службы, которые располагаются в /etc/systemd/system. Это позволит легко отслеживать изменения и обновления системы без потери производительности.

Каждое из предложенных решений имеет свои преимущества и недостатки, и выбор зависит от ваших конкретных нужд и уровня контроля над системой и её конфигурацией.

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

С уважением,
Ваш IT-эксперт