Служба инициализации не включается после создания файла службы systemd
Я бы поменял это местами. Вам нужен код, который вы разрабатываете, для доступа к некоторым конфигурационным файлам в каталоге, который, по его мнению, является /etc/ (и может быть подкаталогом в нем, хотя вы не совсем поняли).
Вместо того чтобы пытаться найти способ подделать это на уровне файловой системы, сделайте то, что делают многие другие приложения, и предоставьте настраиваемый каталог конфигурации.
Скажите своему приложению, что файлы конфигурации находятся в /home/user/prog/etc/ или /usr/local/etc/ и отлаживайте его таким образом. Жесткое кодирование каталогов конфигурации плохо по ряду причин.
Как только вы сможете изменить, где ваш код ищет конфиг, вы сможете тестировать столько, сколько захотите, без доступа к /etc/, который, как я предполагаю, является корнем вашей проблемы.
Теперь я обнаружил, что проблема была в том, что в служебном файле, автоматически генерируемом systemd-sysv-generator, отсутствовала секция install с опцией WantedBy. Я добавил следующее в мой сгенерированный файл /etc/systemd/system/programexample.service, что позволило мне правильно включить службу:
[Install]
WantedBy = multi-user.target
После этого я выполнил
systemctl daemon-reload
чтобы убедиться, что мой служебный файл был прочитан systemd.
Теперь я получил соответствующее уведомление о том, что моя служба действительно была где-то по симлинку "включена":
[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.
Эта ссылка помогла мне лучше понять файл службы.
Мне не нравится то, что systemd-sysv-generator по умолчанию не включает секцию установки с опцией WantedBy. Если systemd может динамически читать заголовки LSB и правильно запускать службы при загрузке, почему бы ему не генерировать служебный файл соответствующим образом? Я полагаю, что следует ожидать некоторых трудностей, связанных с ростом systemd.
В моем случае проблема возникла из-за двух разных версий Java в системе, из которых одна версия (Oracle JDK )была установлена позже установки на jenkins в моей системе. Я запустил команду альтернативы -config java и установил для java открытую версию jdk, которая была установлена вместе с jenkins. и перезапустил службу сервера jenkins. Вот и все.